This is a draft of my idea:
https://github.com/aybehrouz/AVM/blob/main/proposal.md
I would really really like to know your opinion about it. you could comment here or on the github rep. I would really appreciate it.
(Update: I added the “Incentive Mechanism” section)
It looks really well thought out, unfortunately I don’t know how to program and I didn’t understand much. What is it used for, does it help with creating transactions?
Thank you so much for your interest and for your question.
Currently, Algorand is not a smart contract platform. It’s actually a payment platform with some scripting capabilities added to it. TEAL is limited. It doesn’t even support loops. To add more smart contract capabilities Algorand is going to use a Two-Tier Architecture (as much as I know):
https://www.algorand.com/resources/blog/algorand-smart-contract-architecture
In this approach, smart contracts that can not be implemented with TEAL must go into layer-2, which essentially means they have to be “off-chain”. In other words, they will be run on another chain which is secured by a different validator set, called smart contract execution committee. Each validator on that committee executes the contract call and generates a sequence of effects which is the sequence of transactions generated by the contract call. these “effects” then will be applied to the main chain.
To be honest, I really do not like this design. Layer-2 contracts have an ambiguous level of security and writing them will not be easy. When you are writing an off-chain smart contract, You have to be speculative about what’s going on in the main chain. You can not be sure about account balances, the time your transactions will be applied and etc. In my opinion, this design has almost no benefits.
Recently, I’ve been thinking about this subject. Maybe I’m wrong, but I think we could have efficient general purpose smart contracts right in layer-0! I call it layer-0 because in this approach everything will be run on a VM. Even transferring ALGOs can be implemented by a smart contract running on this VM. Actually that way, things also could be implemented much more efficiently. This is possible with the help of ZK-EDBs which is actually an invention of Silvio Micali himself. Having a VM also has several other benefits: writing compilers is easier, the design of our platform will be similar to a normal computer and we can borrow technologies from other areas, transfer logic of assets including ALGO will be more transparent, and so on.
Look like the idea is more secure and efficient.
However I’m not computer versed. Will using VMs compromise the network etc?
Maybe you should get in touch with someone from the Algorand team to run it past Silvio and to get his input?
Thank you for your question
A VM could provide a secure environment for running smart contracts. When we use a VM it would be almost impossible to use a malicious smart contract to attack the node software. (node software is the platform that executes the smart contract) but I have to also admit that having a VM like this one, will make smart contracts much more flexible. You would be able to implement anything you can do in a normal program in a smart contract. Unfortunately, this will make smart contracts more prone to have software bugs. I hope by developing better tools and good standards we mitigate this problem.
by this proposal I’m trying to:
Smart ideas @aybehrouz ! Actually, Smart Contract is one of my key interests in blockchain and any topic around it gets my attention. From the subject post, it’s unfortunate to note Algorand cannot handle SC at the moment. Any on-chain challenge necessitating dependence on a 3rd party protocol in a supposedly trustless platform is a NO-NO for me. Like @Kobs87 suggested, you may do well to find a way to run this by Silvio. Good thinking 
Thanks a lot for your support @Rankyn
When I wrote this proposal I really didn’t know where I should post it. Etherum has a git repository for improvement proposals:
https://github.com/ethereum/EIPs
When you have a proposal, you submit a pull request to that repository. It has a clear guide that explains how to do it and how your proposal will be reviewed:
https://eips.ethereum.org/
https://eips.ethereum.org/EIPS/eip-1
Unfortunately, we don’t have something like this in Algorand. So I just assumed that the best place for posting my proposal would be this forum. I’m not sure if Algorand lead designers check this forum or not. I also tried the discord channel, but I realized discord is not good for this type of posts… in discord your post gets buried under newer posts quickly and few people will see it, unless you spam it again.
Currently, the Algorand foundation is trying to build a community for “building on Algorand”. That’s really great. But “building the Algorand” itself is important too! The community could help with that too. I really think that the Algorand team should start actively involving the community in the process of design and implementation of the Algorand protocol. The current design of Algorand is far from perfect and it really needs the help of the community.
Algorand has smart contracts support:
I agree that it’s use is limited, but it’s powerful enough to create complex apps, like: permissioned voting, permissioned tokens (securities), AMM, … It has different computational model, and it has limitation on the size of the program.
I think by increasing the current program size and including more primitives, especially for advanced cryptography, we will not need a more general purpose VM. Blockchain is an expensive platform. If we want to have a high speed, decentralization and high security guarantees then we can’t have general purpose on-chain computation.
Other solution would be to do only Zero Knowledge validation - so the chain will only validate state commitments with zero knowledge state commitment transition. That would be the most optimal solution IMHO (however it’s very complex and involves problems of who and how stores data).
There’s already work started for off-chain contracts as well.
I don’t think that’s a problem because we don’t need to trust the servers that store our data and we can use transaction fees to incentivize them. Actually my proposal is mostly about the usage of ZK-EDBs (zero knowledge elementary databases). If you were interested you could check this section:
https://github.com/aybehrouz/AVM/blob/main/proposal.md#implementation
For using ZK-EDBs effectively, we need to have a unified memory structure in the node software. We should use the same memory model for smart contracts and users balance record. In my point of view, the best way for doing so is to have a VM and run everything (including ALGO transfer logic) on that VM. Then, we may use different methods for persisting the memory of our VM, it could be a normal data base or a distributed ZK-EDB or anything else…
Why shouldn’t we provide general purpose (i.e turing complete) computations on a blockchain platform? Is it because we have limited computational and memory resources? If that’s the case then the conventional way for controlling the resource usage of a program is to use a VM. Currently, the main use case for Vmware and KVM is resource management in cloud platforms. With a VM you can precisely control the amount of memory or even the number of clock cycles a program is using, and if you can control the execution time and memory usage of a program why do you need to limit the programming language capabilities? (i.e. TEAL capabilities)
In terms of performance, it should be noted that Limiting the programming language capabilities will not give us any performance gains while we are running our programs on a general purpose hardware. If we had a specialized hardware optimized for our programming language that could be helpful… but we don’t have that hardware.
Current design of TEAL is not performance friendly at all. TEAL uses a map data structure as its memory module, it has type-aware instructions so you always have to perform run-time type checking, it has instructions of arbitrary length (byteC and IntC) and, last but not least, TEAL uses an abstract stack machine. A stack machine is easier for code generation but its not good for performance. Its performance is much worse than a register machine specially when your underlying hardware is a register machine.
In my point of view, the best justification for having a limited PL (programming language) is security. For example, we could design a PL which can easily be verified by formal methods. This is really a good idea, but we can have such languages on a general purpose platform too. We could have both a limited PL and a general purpose PL and developers can choose the language that is more suitable for their needs.
Side-chains is not a smart solution for a problem. Its not a solution at all. Its just a way for ignoring a problem. If you can run your program on a side chain with a considerably less security, why don’t you run your program on an efficient centralized server?
For a PDF version of this proposal:
https://github.com/aybehrouz/AVM/releases/latest/download/avm.pdf
I have added some ideas to it recently…
Also, I was wondering if there is any blockchain that has similar/better ideas than these ones… I would really appreciate it if you inform me about such a project.
this is interesting… any updates on this from the team? the proposal makes sense.
There is already a prototype using PointProofs designed and implemented by Algorand.
Hi @aybehrouz, having a VM inside the chain got popularized by the success of Ethereum, we call this blockchain 2.0. IMHO, when Silvio started to work on Algorand design, he was solving the Blockchain trilemma (which he did with VRF based consensus). He also rejected the idea of having a full turing complete VM (DAML also is not turning complete by design). I noticed the the Teal VM is quite similar in design to Bitcoin scripting.
However, in the Blockchain 3.0 world, the dominant though is on having shards, sidechains & rollups. Ethereum 2.0 and Polkadot both don’t have a smart contract at L1.
I am also contemplating upon adding a VM to algorand, and use it as a L2 layer.
You can either plugout the teal VM or add some instructions into the existing VM like adding OP Codes for ZK-EDB .
In case you wish to experiment with any of the two ways, I can point you the the respective programs on the algorand source, and hooking points.
@rains thanks for sharing the link! This is really worth exploring for me, as I am looking at the Layer 2 solutions on Algorand. There is an excellent paper (from algorand members) here, see: mit paper on aardvark
@aojjazz I had read this post multiple times in past few months, however, one point that is intriguing for me is “The contract execution committee is chosen by Algorand’s secure, randomized, self-selection algorithm, just like the main consensus committee” , the blog itself does not clarify how. One possible way is to run Algorand as a sidechain and build a asset transfer bridge to the main chain, alternatively use the Thorchain TSS architecture.
I would be interested in hearing your thoughts on this.
Hi @innomon
This is an old topic. It was created more than 4 months ago.
This paper is not a proposal for Algorand anymore. Currently, I’m trying to continue my project independently:
https://github.com/aybehrouz/ADAGs
I do not follow Algorand projects and I’m not interested in any of their programs. Thanks.
why? what led you away? what do you think of algorand’s new VM seems they took the path you offered on VMs
As you can see, they didn’t show any interest in my proposal.
you suggestion is very different from what is built and they would have to start all over. Not sure if yours is better though.good luck in all your endeavors, contribute when you can