For 1st layer: TxVM + IvyLang would be very good beginning point I think.
For 2nd layer: I would suggest an UTXO Contract generative DSL in this deck
Agree with that. I think the test of the base layer should be whether @fubuloubu could build his system on top of it. I think that itâs a system that would appeal to many people, but I personally wouldnât want to be forced into it.
Well, I wouldnât say the point of my system would be to force anyone to do anything. It would work the same as it does today, but the additional features would give assets first class citizenship in the platform. A more strict data model leads for better reasoning and optimizations on both the design of applications and the protocol layer.
People are still free to design arbitrarily complex contracts with state storage and access, but this would make it easier to adopt better standards of interaction and gives tools for the whole state rent storage situation.
I think if you identify very clear use cases of the platform, more specificity is actually a welcome and efficient experience from all perspectives. The alternative is a jumble of ERCs for token standards with different properties that canât be abstracted.
I think the ERC process has led to some great work, and Iâm really glad that our core primitives such as ERC20 werenât all hacked together back when the EF was running out of money and struggling to launch the main chain on time.
1 Like
Absolutely! It has led to so much innovation and exploration of the design space.
It has also led to an entrenchment of standards, ERC20 is the best example of this. Despite several passes at improving it, it will continue to be the most widely used because network effects. I donât see that ever changing with new ERC proposals. About the only thing that could overcome it is a better facility solidfied by the core protocol. We should take what weâve learned and make it easier and safer to use!
I think Vitalik might be right on this one. @fubuloubu remember we briefly spoke about Dfinityâs Primea, do you think something similar (communication âmiddlewareâ which includes the actor model, optional synchrony etc) could also be the optimal solution here?
Sure, that is definitely one approach. Layer 2 systems could definitely use this model. I would argue many already do (as well as in layer 1).
The point of my original post was that it came from a place of general analysis of what has been built over 3 years, and what has seen widespread usage. The idea is to add new features and new data structures (which does not affect the current design of contracts at all, so it is entirely opt-in) that helps contract designers more easily program with the primatives they already want to use.
How much percentage of the network, dapp design, layer 2 architectures, etc. are asset transfers of some type? How much of what we design has to do with ownership in some way, shape or form?
If well adopted, this framework could allow the design of state rent control and sharded communication architectures in a more direct way, as the data model would be more specific to the types of state and communication that is being used, allowing better optimization to those use cases.
This could be migrated in a smoother and more gradual process, and does not require conducting new research or validation of new algorithms to be successful. It just takes an eye in optimizing for the 90% use case, which reduces the burden on the network. General purpose computing is still possible, I just donât think it makes sense to optimize for it because thatâs not how the system is being used. Optimize for what is!
2 Likes
Would also like to note this is optimization for inter-contract communication. Stateful asset passing is something all contracts already do.
The design inside a contract still can be whatever and however you would like to design it. Solidity/Vyper/etc still work.
Itâs the same reason we added precompiles for common cryptographic operations instead of making every user/language implement their own. It just seemed to be what people used most. 
Totally agree with this.
For posterityâs sake: https://github.com/jodal/pykka
I dare someone to write an asynchronous sharding model PoC using that and websockets lol