I'm currently reviewing the paper as of 0.8.5. Certainly interesting. One downside is that it requires not one or two but I believe 8 new opcodes. Will follow up with thoughts that I'll also share with the authors
should not be using strings when we can just use byte arrays (why use substr opcode if we're dealing with bytes not strings??)
requires 4 introspective opcodes implemented in elements, OP_CAT, a new opcode OP_VERIFYSTARKPROOF, OP_SUBSTR for substring ops (reduced by above?) and OP_TWEAKVERIFY (8 missing opcodes in bitcoin)
account-based blockchain is a primitive design and is inferior to a UTXO-based blockchain. it encourages bad practices like address reuse and creates unbalanced transaction loads, making scaling either harder or impossible
deposit amounts should be 64 bit rather than 32 bit if possible. there are 2.1E15 satoshis, and 32 bit can only represent 4.3E9 satoshis. this could be a space saving optimisation however
The global state of all accounts is stored in a Merkle tree of height 40, which allows for over one trillion accounts.
what happens when we go past 2^40 accounts? will collisions occur?
confirmation times on rollups still match confirmation times on the base chain, and account based ledgers are not private, so something like lightning might work on top, potentially using optimisations like eltoo and other things we'd otherwise have to modify the base chain for
censorship of L2 transactions needs to be considered, distributing the Block Producer is important and can mostly solve this. A modified version of Raft can be integrated for consensus
account-based blockchain is a primitive design and is inferior to a UTXO-based blockchain.
there are tradeoffs involved with account based chains vs utxo chains. one isn't necessarily better than the other. which is better depends on the use case at hand (and for some use cases, either would work just fine)
it encourages bad practices like address reuse
there are privacy solutions like firn, railgun, and umbra that mitigate or negate the harms of address reuse.
and creates unbalanced transaction loads, making scaling either harder or impossible
there are already account based chains with parallel transaction processing. though even with sequential processing, chains are getting to pretty large scale already. anyways, at a certain point, it makes more sense to shard execution rather than keep scaling the same execution environment if the goal is preserving decentralization. all that said, since a bitcoin rollup would be limited in scale by bitcoin's data availability capacity, scaling isn't even the main concern here.
what happens when we go past 2^40 accounts? will collisions occur?
no, past the limit you just can't create any more accounts.
no, past the limit you just can't create any more accounts
Awesome!
there are already account based chains with parallel transaction processing
Yes, however UTXO based chains can achieve near perfect distribution and scaling (I researched and designed this for an L3 on lightning built for performance), unlike an account ledger. The actual implementation can become much more efficient too by removing things like locks from the implementation entirely. Account ledgers mean that simple (therefore fast and reliable) ways to partition the layer don't work as accounts can have vast differences in activity. The UTXO model enables perfect distribution - basic properties such as transaction and public key hashing can be used/exploited to achieve this.
This L2 could be implemented as a UTXO layer too, so this is not an issue with core features (the ZKP and Taproot/MMR integrations are fantastic) but rather an improvement to this!
there are privacy solutions like firn, railgun, and umbra that mitigate or negate the harms of address reuse
Yes, this is awesome. However, privacy shouldn't be a bolt on addition for a settlement layer. UTXO chains are superior privacy and security wise - a UTXO model also counters most practical quantum attacks too as the signature is revealed at most for a short amount of time and never reused, discounting that clients have to be built to support a more complex UTXO model. Though bitcoin's had no problem with this and it's basically a non issue...
However, privacy shouldn't be a bolt on addition for a settlement layer.
What meaningful differences do you think there are between having a privacy app like Railgun vs making privacy a "native" feature at the consensus layer of the chain?
a UTXO model also counters most practical quantum attacks too
This weakness of the account model can be mitigated by using a PQ signature algorithm in the L2. PQ signatures tend to be relatively large in size but with a ZKP L2 we can aggregate these signatures into a single PQ ZKP (e.g. STARK) so that the L1 footprint is no larger than it otherwise would be.
I am curious, are you an author from Alpen?
I work for Alpen but was not an author on this paper.
I also have my doubts that something like OP_VERIFYSTARKPROOF would actually get into bitcoin because of how computationally heavy it is, but that's a discussion for the community to have.
I imagine we'd weight it accordingly using something similar to the witness discount (but more like a "witness premium"), or using GSR-style varops budgeting.
OP_VERIFYSTARKPROOFwould actually get into bitcoin because of how computationally heavy it is, but that's a discussion for the community to have.