I want to share some of my thoughts about scalable blockchain based (at least payment) system, not sure if it the right place.
Nothing is correlated to Zcash official roadmap and technically deep. All the imaginary possible future. Just my personal opinions.
Make blockchain succinct and smash distinction between light and full nodes. Blockchain weight won’t be a bottleneck anymore but network and block producers is.
Transaction confirmation time: few seconds.
Get rid of historical transactional data
With history proofs like in Mina, or organizationally (history expiration, snapshots).
Up to few times of scalability improvements
Get rid of the state
Make block production stateless. State should be maintained by wallets or off-chain otherwise. Minimum required data as a state roots, proofs need to be stored in a block header.
Wallets could create correct transaction with their data (previous outputs, data entries). Validators or block builders could validate transactions over the latest block header with state roots and create a new one.
OK, the blockchain is succinct now.
In the first step validators collect all the known transactions in the network and create a new blocks sequentially. Further scalability improvements will be require some sort of concurrent processing.
This part will require significant network improvements. Currently blockchain nodes not very network intensive, they get transactions from the network, usually dumb gossip network and verifies over the local database, then gossip the new correct block. But scalable P2P payment system will depend on synchronous communication more.
Transaction confirmations could be nearly instant.
I assume two possible options here but not limited.
Option 1: Transactions aggregation
A new role, an aggregator, will listen network for transactions and send aggregated summary to validators. Aggregated transactions is enough to create new block (header) if two of them don’t have conflicting transaction. With conflicts the network performance can degrade. So, aggregators should separate their duties, and exchange some short commitments about what they have. Bad behavior can be limited with fraud proofs and penalties. In the better case aggregated transactions with conflicting tx won’t prevent the block building as conflict can be separated from resulted block or state root.
Option 2: LN-like network with validity proofs
The current bitcoin Lightning Network has limitations: It uses fraud proofs and don’t send info about channel transactions to the blockchain. Better more trustless version should be possible if after every channel transaction emit an aggregatable proof about the channel state to the network. If a current LN channel is like a plasma, to in a future version it can be more like a validium. Safe fast uncooperative channel closing, updating, splicing would be possible as well as multiparty m-of-n channels. Better UX with great scalability.
Two-step transactions (building)
Some blockchain designs require interactive transactions building (MimbleWimble, Lightning Network). It often seems as a drawback for UX but it can be seen as an advantage.
A single-step tx:
Currently (in bitcoin) if Alice wants to send coins to Bob she moves coins to an address controlled by Bob’s private key (create new output controlled by Bob’s privkey). Maybe Bob will never know about the transaction, but Alice won’t get coins back. What if Alice send coins to a wrong address.
A two-step tx example:
Alice send coins to a new output which is a smart-contract where:
- Bob can redeem coins by his private key for a limited time.
- Alice can get a refund after that time (can be considered as auto-refund as Bob can get it anymore).
But what the advantages of this?
All the transfers consciously accepted by both parties. No more spams, airdrops, dusting attacks. Sending to wrong address and wrong networks is not a problem anymore as can be refunded. More clear payment acception (for example, now consumer can see that a payment is confirmed not only by the blockchain network but also by a merchant).
It even more important for a full stateless chain. Bob now need to know that tx exists, and get data (outputs) required to create new transactions with this coins. This can be done directly between wallets in a synchronous P2P messaging network.
Generalization of UTXO
I don’t know how good UX of stateless general-purposed blockchain with smart-contract can be in comparison with current stateful (or weak stateless) chains. But at least it should be very suitable to settle validiums.
My intuition tells me that UTXO and account models should be interchangeable. It is possible to make account abstraction on top of UTXO chain, and implement UTXO transactions as a contract on an account chain, to create an UTXO L2 on top of an account L1 and vice versa.
Generalized UTXO now looks like UTXO with turing-complete spending scripts. It can be multi-asset chain with spending scripts or private chain with confidential assets and turing-complete spending scripts. Anyway, it has some token transfer event as a core of an output.
But UTXO can be implemented over arbitrary data records without any transfer primitive with covenants discussed in the bitcoin community. And tokens can be implemented as custom covenants.
Account and address abstraction
I think addresses should not be a part of a blockchain protocol and implemented in wallets, maybe for communication purpose only. With interactive transactions they are not needed anyway. If Alice and Bob transacting over Signal they don’t need addresses. For sending between addresses is better to do with communication addresses of overlay messaging network similar to onion-addresses in tor/ And not with addresses derived from privkeys which control funds.
Blockchain protocol is better to keep minimalistic, simple, clean, succinct and universal as a basic low-level protocol.