foreign
[Music]
yeah you can hear me right
and I hope this works as well
okay it does
um
yes Francie said uh thank you for the
intro and I wanted to also make sure
that um
a lot of this stuff is my opinion it's
not like the opinion of the team I have
been working on solitary since 2015. and
in the past year I've been kind of like
taking a break and uh did write a lot of
code in solidity itself
and I think some of this is like a
culmination of of you know my experience
using the language but I hope some of
these things are mentioning may come to
infusion okay so 0817 is the latest
release
it's a hundred second release we already
had more than 100 releases that is just
insane
and we probably have more than like a
thousand night leads which is
just crazy basically we had eight
breaking releases a bunch of feature
releases and sometimes we do have like
bug fix releases as well
um in some of the years we had releases
every two weeks I think lately it's more
like monthly
um and I hope that's going to come to
you maybe you're gonna get back to like
bi-weekly releases but at least want to
release this and I'm saying this just to
show that how active the development of
solidity is
I'm not gonna go through all of these
um you can find this really nice chart
on the solidlank.org website and it
shows you all the interesting milestones
we have accomplished since the beginning
however it doesn't show anything past
0.6 because he made this two years ago
but as you can see it's it's a lot of
stuff going on
and based on like having over 100
releases you may ask a question when do
we actually get to 1.0 and you may not
be alone asking that question we do get
that question super frequently last year
there was like this big debate
um this particular issue I'm looking
here
the issue is much longer the description
is maybe 10 times as long and the author
of the issue provides a bunch of
different reasons why he thinks solidity
should be at 1.0 I summarize like three
different discussion points we have been
debating on this issue the others that
or had the opinion that the current
scheme doesn't actually allow breaking
releases the separation of breaking
release and non-breaking releases in his
opinion on every single facility release
is a breaking release
he also argued that the languages
widely used it is
it has been for a couple of years and so
it should should be a 1.0 because that
signals that it is ready to be used
um in fact
you know when 1.0 was released we never
signaled a 0.1 was released we never
signaled that it's ready for usage but
the nature of blockchain it just started
it people just started to use it and
it's there it's always going to be there
um but also the team had some concerns
about this 1.0 stuff basically we have
the impression that 1.0 kinda implies
that we have to have a long-term
maintenance of that version we have to
add new features non-breaking features
um and all kind of changes and if we
still want to do braking changes that's
going to be like 2.0
and then suddenly we have to like
maintain two versions or we're not gonna
make breaking releases so that that is
the reason we kind of wanted to avoid
going to 1.0
I'm not sure how many of you actually
know how the versioning system works
um do you want to like give hands on are
you a developer first of all
so many of you are using solidity are
you using anything but solidity not many
any other language besides solidity nice
so I think you should you ever had this
versioning system works
um we've learned the impression that it
is semantic versioning turned out it is
not
um because anything below
um the major one so major zero is a
breaking change however we did assume
that
um you know the three three numbers in
the version is major minor patch and we
assume that if we bump the the minor
that is a breaking release if we bump
the patch that is a non-breaking release
so it's not actually in conformance with
semantic versioning but it kind of works
for us
um here's just an example you know how
this would look like and now suddenly
you know once we know what 1.0 could
mean maybe we should talk about how
could we get there here's an example
contract
um with the latest release this is
actually the solidity stocks contract
which is on mainnet you can use it to
make socks both the land and the right
hand side if you're lucky you can you
can win both and uh I think the stocks
are gone at this point but you could
have gotten them a physical version of
the stock at the solidity stand
um I think on the floor above I'm not
sure
now this is 0 8 17.
it is 1.0
do you see any change
yeah I kind of think that actually for
the users you're not going to see too
many changes at 1.0
we may actually have some changes
okay so that was the the non-changed
version
skipping one
okay this is an unchanged version
and this has a few changes
they're not important
yeah um where is it like this stuff
this stuff all of none of this is agreed
on
but there may be tiny changes but I
don't think they're going to be big
changes
um so no major difference is if you're a
user but giant difference is if you are
writing a library
um I listed a few things on what you
would be able to expect in libraries
we should have like operator operators
and letters to use the defined types
standard Library generics
um you know data types I just gave you a
few examples now but actually
Daniel from this already team had an
extremely good talk which you should
watch and I'm going to share the QR code
for the video as well so here's an
example of user defined operators
I cannot see that I actually like the
syntax but
the team kind of agreed on it so without
tests you have to use the usual function
chaining but once you have user-defined
operators
you know what you can expect you can
just use them fairly easily
so I think the team kind of agreed that
this is going to be in uh this is going
to be a focused project and
I believe this is needed for like 1.0
another major thing is a standard
Library which
we have been talking about for years
and the main goal of the standard
library is to move out the majority of
the compiler code into solidity itself
but it is also really good exercise
doing it because it shows us what kind
of language features are missing so
here's one example this actually doesn't
require anything major the only thing it
requires is this pragma standard lab
and what it does it just disables the
built-in functions because if you don't
have this primary standard lib this
function definition is going to fail
because there's already a shot 256
implicitly in the language if you have
this it's not going to be there so you
can define it
this is the simplest example in the
standard library and this works doing
anything more complicated going to
require a lot of language changes
here's one example what we will require
for the language changes it is just
generics
there's a this is an extremely old
example
and in fact I copied this example from
my talk from two years ago from this
holiday Summit you're already seeing the
same things back then
so I'm not going to go any further if
you want to take a um a photo of the QR
code this is the talk from Danielle it
is a full 30 minute talk and it did a
really good job at explaining the
reasoning Behind These features and how
they're going to work
okay now taking a tiny break
these were the changes the team wants
and the team agrees on
but I kind of want to ask you all of you
to look at the Repository
this these are all the it's kind of hard
to see but these are all the issues Tech
language design
and we have 237 issues open those are
the issues people want want as a feature
and I think many of them actually are
kind of obsolete at this point
um but I ask you to look at this
repository look at all of these issues
or you know a tiny subset of them find
something what you like and leave a
comment if you want to have it or leave
a comment if you think it is a bad idea
you know besides these features that the
team wants I think it would be nice to
know what you guys actually want
so I think that's what 1.0 gonna be like
um not many like visible changes for the
user side
if you're just writing like a token
contract NFC contract Etc but if you're
writing libraries it's going to be
entirely different you know one 2.0
that is a crazy topic
and uh
we have been actually talking about this
for a couple of months at this point on
and off
and actually 2.0
it's two different things
and it has been like super confusing at
the team even talk about it because you
know some people meant the one or the
other
and I just want to highlight it again
you know nothing is decided here a lot
of this is just uh you know my idea what
I want to have
um but I hope some of this is going to
happen so first I can talk about like
this compiler rewrite
where it sounds crazy right
um how many of you actually know the
compiler how does the compiler work
or a compiler in general
not many of you
um
basically a compiler has multiple stages
you know we take like the source code we
process the source code into some
internal representation uh we do a lot
of different analysis on that
representation once we are happy with
the code that it is sound that it works
uh we are generating some kind of a next
stage
in the first version of the compiler
this generation was directly into evm
in the current stage we already have we
we still have this but we also have a
second pipeline where instead of uh
directly generating to evm we generate
it to Yule which is our Intermediate
Language
um but you must be familiar with you
because it is a line assembly basically
and then we take fuel and generate evm
byte code
so that is the the pipeline and then
these are the different libraries we
have in the compiler itself
so this one is just really tiny helpers
I'm going to move to the other side
um so these are just helpers used by the
others the assembler is a
kind of separate it's it's standalone
it takes in a data structure like the
representation of the the assembler
source code you want to assemble
um byte code but it also has
optimization steps
then we have this separate helper for
it's called language utilities but it's
really just helpers for the parsers
because we have two different parsers we
have the solidity parser and the yield
so Lang duties is used by both of these
uh the Libya has a parser has a code gen
has another kind of optimizer
and then lips solidity is a big one uh
it's the it's a monster it is it's
already departure
um does all the analysis I mentioned and
does these two different pipelines for
code generation
and then we have two smaller libraries
the smt library is just for the SMD
subsystem but I think that that is also
split up so some of it is here some of
it is in this lip solidity directory and
lastly the smallest one is lips we'll
see which is a tiny binding that is the
only Library which is C has a c API
everything else is C plus plus so this
basically is a wrapper between C and C
plus plus
and that is uh what is compiled to M
script and into JavaScript if you happen
to use any kind of a web app that has
related it would be used
few
maybe some benefits as well but you know
one of the bigger problems we are
getting into is these libraries while
physically separated into their
different directories
um they may not be like super well
separated conceptually or even like
interface wise
um one example I can give which which is
I kind of hit it's not like a
you know logical like um issue in there
it's more like just a source code issue
but we have a
a loop between libu leap evm ASM
um and the front end they're
interdependent on each other
um which is kind of bad if you want to
separate these things nicely major
components they do have some kind of a
clear boundary but it's everything is in
C plus the
the clearest external boundary happens
in two places the assembler has a Json
Import and Export feature
the export feature has been there
forever the import feature
is still not merged but it kind of works
and then solidity itself has this Json
AST import export
I think some tools like Scribble may be
using it
um
basically you can skip the parser no
scribble uses a typical parser but yeah
some people we wanted people to use it
some people use it but they ended up not
using it at the end
um but the main issue I kind of see here
all of this is C plus plus
which is kind of hard to integrate with
other kind of languages
it is hard to integrate with with like
JavaScript we have this m script and
layer and we have the C wrapper it is
hard to integrate with rust you need to
see layer as well although rust does
have like a C plus plus binding
generator it is not really stable if you
want to integrate this into go it's the
same case all of the all of the
languages they only work with C they
don't work with C plus plus
so I have a few you know ideas how could
we resolve this and first of all we want
to just improve the the separation of
these libraries we want to have like
clean interfaces between them and maybe
reduce the number of like C plus plus
features that the interface they're
using to make them more compatible with
c
then
parallel to this because this this can
happen on the existing code base prior
to this we could start working on
components in Rust
and we in fact already have components
in Rust
um we have sources rust which is used
it's used by Faye actually and I think
at some point fan reused it but
they were annoyed by by the size of the
binary and compilation pipeline so that
they're not using it anymore
but we do have a bunch of like libraries
new libraries in Rust which is also used
by Faye and some people in the team now
are working on some crazy features on
top of it
the first useful step could be rewriting
the assembler and the reason behind this
is the assembler is one of the oldest
components we actually never changed
the parser itself has been mostly
Rewritten or at least significantly
improved
um
I think the type system that is also
kind of old but it had more maintenance
but the assembler that is the oldest
component which has never been
significantly improved on
it would be a really good task to
rewrite it and by rewriting it it may or
may not even need to be Rewritten by us
but we could use an existing assembler
and in fact etk the
evm
toolkit evm assembly toolkit I don't
know the what the acronym is for but it
is an assembler toolkit basically for
evm it's written in Rust we could just
use that
in any case once we have some of these
components we could think about creating
a compiler skeleton so basically just a
driver which drives the completion
process
and this doesn't mean that we would need
to rewrite the compiler all we would
need to do is provide trust bindings to
some of those components and then have
this driver which just uses those
components and once this work it works
we could swap out parts of those
components for example the assembler
um because they are just components
and once this this would be working the
biggest change uh would be actually
doing a major rewrite of the front end
in Rust
and the front end by the front end I
mean mostly the parser the analysis and
the type system Etc and while the code
generation is wrong
that is an insane project
and why would you want to do that well
you likely don't want to do it for 1.0
but you want to do it for something else
so what is the reasoning behind all of
this
um the main reason is that we kind of or
at least me when I turn solidity all
this code into reusable compiler
framework
I want to make sure that all the you
know the optimization steps we have all
of these features they're not just
wasted they're not just there for
solidity but they can be used by other
languages
imagine if we would have had like this
compiler framework earlier on you know
it came to like llvm4 evm
you know how how long would it have
taken to Forfeit to to come to fruition
or like half for any of these other
languages if you could just use any of
these components I listed a bunch of
different projects which are already in
the evm space working on Rust compiler
components so of course we have fa we
have the two other solidity
compiler slash parsers
so solang
solank is a full featured compiler from
solidity to webassembly targets well
actually llvm targets they started with
webassembly but they also support like
BPF like Solana and a bunch of other
targets
the one thing they don't support is evm
and in fact solang I believe is used by
Foundry for parsing solidity because
it's in Rust so they're not using
solidity solidity
s-lang is a project by hardhead they're
trying to write a compiler as well the
motivation is slightly different they
want to have a person which is flexible
and supports every single version of
solidity because they want they don't
want to like certify the compiler you
know mid compilation and that's the
problem with the color and compiler it
only supports a single version
so why would we want to do this
because I want to attract more people
to solely compiler development and it
seems like C plus plus is not like a
language people like or people are
interested in
it has been kind of hard to attract
people to to write C plus plus code and
it seems like trust is extremely
thriving
every other project is in Rust I've been
using rust for a long time so I would be
happy for this to happen
and if you do some kind of a
re-architecting like this
that would mean that we have an
opportunity to actually improve the
architecture of the compiler and maybe
improve the language itself so that is
the next one I'm going to talk about is
what kind of language could we have here
you're really surprised or not
but the fact is we have been talking it
like this
um you know rust inspired changes to the
language since 2019 way before some of
these are arrest inspired evm languages
came about
oh it's actually another sign
um I think the main motivations the main
reasons those discussions were started
because there are a few issues in
solidity itself or at least a few issues
I think should be at rest
one of them is really the storage and
implementation itself is not really
separated so the other thing we have
right now is this contract construct it
can have storage defined anywhere it can
functions defined anywhere
it can inherit other contracts which
also Define storage and functions
anywhere
and you never know where storage is it
could be handled by any of these
imported libraries it would be nice to
actually make this more clear
the other thing would be nice to kind of
make clear when State changes or state
access can happen
we do have some of this in the language
today
um you know via payable we have View and
pure functions but that's about it it
would be nice to you to have like more
clarity even within the functions when
is a state change taking place
functions can be quite long I think good
code bases started to
create small helpers and limit the scope
of like State changes to those smaller
helpers but it's still people can write
no matter what you do people can write
really bad code but in solidity
especially people can write like giant
pieces of coding would be nice to have
like Clear View whereas State access and
state modification taking place
and lastly if we you know take such a
big step
um we could even consider
removing like inheritance or looking at
like a different way of composing the
source code
um and in fact if we have like more
clear control about the storage maybe we
also have more clear control storage
layout which has been like a really
annoying question and I know many of you
have open issues how can we like set
like slot numbers Etc
um some older contracts have like these
padding storage items it's insane
okay now finally
what would it what could it look like so
here's an example
I'm not sure if any of you recognize
this it looks like trust but more
specifically no it's not sway
it's Faye
this is actually say and uh
they started to basically do all these
steps um we were discussing
um which means
having a context
which is like a clear separation of
State access
um
okay this is what's on the website but
um yeah this is another one which is
nice
um you know not having like special
constructs rather have it tied into
State access
um and I think they also like changing
it from having a contract and all these
things to having uh separate pieces
now here's a real example of
what is more like what we discussed
under like thrust solidity
um do you have like a separation of this
could be contract could be struck people
leaning towards struct so this would be
really just the data
and then that would be the
implementation I mean it's not too
different to what the
uh fee is trying to do now and this is
the distal contract I had as an example
before yeah I mean that's it really I
only have 10 seconds left
[Applause]
[Music]
thank you I guess we can take one
question
if somebody has a question please raise
your hand so that the mic can find you
hey Alex so just a simple question you
got you're talking a lot about rest
but have you guys give a talk to the
Cabo that's like the new language
that they are going to upgrade C plus
plus
carbon it's interoptable so you guys
could like reviews oh yeah yeah the C
plus the new C plus plus right yeah yeah
experimental yet but guys would be able
to use everything that's written so far
I'm not sure what benefit that would
bring
um it's worth a thought yeah yeah I
think we
I don't think we had a look but we heard
about it
unfortunately time's up but thank you so
much Alex