Editing Thoughts on blockchain scalability (section)

= Towards adaptable consensus =

[https://lightning.network/ Lightning] is an essential tool for off-chain scalability, but you cannot use it for complex, on-chain state transitions like the ones we see in Ethereum. For this reason, most of the research on on-chain scaling has focused on introducing small amounts of centralization to make improvements to scaling, but from my perspective, this is still the wrong approach.

What we seem to need isn’t a single, consensus algorithm for every purpose, but an algorithm that can adapt its economic security guarantees to the required use-case.

In practice, this doesn’t mean that consensus should be “proof-of-stake”, “proof-of-work”, “delegated proof of stake”, or something else…. But that we need to start modelling consensus in a higher-level language based on the resources used and the benefits gained from doing so.

Our requirements may be greater transaction speed, security, or privacy. Whatever the trade-offs, the consensus algorithm needs to dynamically adjust the resources used to meet those requirements.

For example, if you only want to make everyday payments that are low value you might be satisfied with using a few servers for that ledger. It would resemble a slider of resource-usage that is adjusted based on needs, with a way to migrate funds to the more secure levels as needed.

Moving up to a higher security level would mean reducing scalability by some factor of ten, but it would also mean that between any two security levels it would be possible to move dynamically between levels without incurring too much of a performance penalty.

<span id="domain-specific-consensus-language"></span>