Thread by @paddyucl

Last up is @hkalodner telling us about his work on Artbitum :) #offthechain (on 5% let’s hope I last)

How can we scale smart contracts? We could try snarks, but slow. We can tried incentivised verification (truebit), no privacy. What about state channels? Dispute resolution can be problem. One component though!

So this protocol aims for rptocol design, incentives and a new virtual machine architecture. No fancy cryptography. How does Arbitrum work?

Main idea: we have a virtual machine. And there is a “any trust” guarantee - if at least one manager is honest and available. Code always

Runs as expected. Any other VM oubdont have to trust, can just ignore it. A rogue VM can not interfere with other contracts. Just care if they send us money. How is this used in practice? Goal is managers have agree Unanimously about what is going on.

He begins with the initial state. Machine does lots of steps, and then eventually does some action. Signatures by all the managers. We send to the blockchain and it is confirmed. Now this is all on chain. Works nicely; but we want to get it offchain. If we want to scale messages

We can use state channels; but what if the managers do not agree? We can get around it with a disputable assertion. Any manager can assert; we then have a challenge period, loser loses deposit.

During any challenge period - it is somewhat like truebit it sounds. Managers work out what task they dispute on... and the initial assertor needs to split it into two... n/2 what is the state? If I agree; then problem must be in the second half.

They can keep disagreeing (in some form of binary search thingy) and then eventually find a task they disagree on!

How big is the one step proof? How costly is it to create and verify? Do I need to post 10 mb? Let’s find out if my battery doesn’t die (1%)

He proposes a custom VM architecture - to help make the proofs small and efficient. All instructions can be emulated in “constant” time. One step proofs are small: so even having an arbitrary amount of state or code; no impact on the proof size. Every state is a merkle tree with

Limited degree - getting branch is small. And each leaf has a limited size. Instructions on impact items near the top of the tree.

We cannot use this with flat memory. If you want VM to read info in some random location... still not constant size. The VM have types which is a tuple (can be recursive, lots of tuple). Then we can just do a logarithmic number of constant instructions (right left right left)

To eventually get to some arbitrum value.

Here is an example

One impact is a “private smart contract” and more than the state channel approaches. In a dispute, you only reveal a small amount of information. We don’t publish full VM. We could have a manager leak the info... not much we can do.

They are now working on one step proof in zkp

This is their system - they have a native implementation of hash functions. They can do this in VM. Each VM can execute in parallel.