Blockchain Security: Will it scale? Our tech lead Esteban Eordano writes about scaling Decentraland, blockchain security, and DPoS

Blockchain security, DPoS, and how we plan to scale the transactions of the Decentraland ecosystem without drafting a constitution

How do you build a decentralized application that can support an increasing number of users, without sacrificing security? Building any application that can scale is challenging enough, especially one that relies on a blockchain to verify transactions. So far, 2018 has had blockchain experts and developers focused on increasing the number of transactions dApps can handle, since it’s obvious that user experience demands higher throughput. In the short term, the throughput gold medal goes to EOS, a project claiming that it can achieve hundreds of thousands of transactions per second.

Why aren’t other projects following their lead?

Can you trust a database?
If Gmail’s servers were wiped clean by a hack, you would lose all of your emails. If iCloud suffered from a massive breach, your data could fall into the hands of any random stranger. What if a Facebook employee accidentally unfriended every single account, across the board, by making a bad commit? Or worse, what if they re-tagged you into all of those pictures from which you had so carefully deleted your name?

We never expect these kinds of system failures from our online platforms. Google, Facebook, and Apple didn’t design their databases to be modified or accessed in these ways. However, “Black swan events” can certainly happen: iCloud has failed in the past, giving anonymous criminals access to personal files. The stakes get even higher when handling money: bank databases face the same risks as iCloud or Facebook. We add a lot of processes, ceremonies, and government audits to make these issues less likely, but there are no ultimate warranties, as the subprime crisis of 2007 has shown us.

In most organizations, you trust that a database is correctly operating because of institutional checks and balances. We rely on the fact that bank databases are protected by logs, audits, and courtrooms: a bank teller can’t just insert a million dollars into her own account, because there’s a number of steps put into place to prevent fraud.

What makes a blockchain secure?
Bitcoin is the first database mechanism that replaced trust in an operator with trust in math, data, and code. Bitcoin takes messages from completely random and anonymous people from the internet, and from these messages it computes a ledger of balances totalling a whopping $100,000,000,000+ USD. That’s quite a miracle. This ledger, worth more than a hundred billion USD, does not require you to trust any particular person or group.

It doesn’t matter who sends the data, it’s the data itself that needs to have a valid proof-of-work and that must follow certain rules. The data speaks for itself. “Vires in Numeris” (a phrase popular in the early Bitcoin community) makes the security model of blockchain ledgers much simpler than traditional databases. You don’t need to check replication logs, or trust that John, the database administrator, didn’t lose his password.

Because it’s easier to trust the math than it is to trust a multitude of individuals, the security of the ledger remains the same whether there are a thousand nodes or a billion. With traditional institutional trust, you have to “watch the watchers.” The more people involved in an institution, the more costly it becomes to make sure that all of the processes are being followed correctly. The more people you involve, the more trust you have to place in processes.

With Bitcoin and Ethereum, you can just run a node and be reasonably sure that the information has not been tampered with. That’s why the Bitcoin maximalists always scream “Run your own node!” They have a valid point: if you don’t have a fully validating node, you can’t be certain of the actual state of the blockchain (and thus, validate payments or know your balance).

If we ran a government in the same way we run a blockchain, running a node would be the equivalent of an AI on my laptop checking every conversation and email between every government official, judging their behavior to ensure they are being honest and diligent.

More security can be provided by running more miners. Even though this consumes more energy, it’s still cheaper than institutional-based security which requires judges, lawyers, politicians, and accountants.

If trusting the miners or operators is required, then a blockchain is no better than a slow database and a costly process to verify and amend it. Blockchains are scaling mechanisms for trust. They allow us to increase the number of users in a system, without asking us to place more trust in that system — or worse, in individuals.

The problem with EOS
EOS is built upon the concept of Delegated Proof-of-Stake (DPoS). This implementation has a number of problems:

Extreme reliance on human-based processes: there are a number of mechanisms in EOS that require a lot of involvement and/or consensus of human third parties. To name a few: a constitution, an account retrieval process, the ability to freeze accounts, a process for denouncing censorship, among others.

With its large resource requirements, the block producers have a significant moat that blocks the arrival of any newcomers who might want to join the club: in order to become a producer, one is expected to run a fairly powerful cluster.

There are no warranties to ensure that the code for a master node’s historical sync is working correctly (and there’s certainly an incentive for this to not work correctly).

Gentrification of block producers: as time goes by, block producers will have a larger fraction of the existing tokens due to the inflation reward. They can then use those tokens to vote for themselves and continue being block producers, even if they were misbehaving.

EOS has no problem increasing the throughput of transactions per second, because it is not a blockchain. Creators and supporters of the EOS project define it as a “distributed, permissioned and neutral database”. The amount of trust-related processes and human-intensive labor required to run EOS place it closer to a publicly accessible PostgreSQL database than to other blockchains.

Regardless, creating a high throughput blockchain is a laudable goal. At Decentraland, we are looking to do the same, but we are determined to adhere to the low-trust characteristics that separate a blockchain from a database, and without adding trusted third parties or human clerks.

Our scaling path
We’re working on a version of Plasma that can run a fully compatible EVM. In our design, the plasma operator (a centralized block issuer) does its best to keep the blockchain running correctly because the operator has a significant financial incentive at stake. The operator must place a big security deposit in the root chain, in this case the Ethereum blockchain. This deposit functions as a warranty: if the operator breaks any consensus rule or stops emitting blocks, it will lose the deposit. Half of this deposit will be burned, and the other half will go to the challenger who detected the problem, incentivizing validators to check that the operator behaves correctly.

In practice, the operator node will be run by Decentraland (at least initially), and it will be kept in check by anyone who wants to run a node and follow the sidechain to validate it. Thanks to the efficiency gains that this model can bring, we expect to achieve a few hundred transactions per second on our sidechain.

This model is similar to a sidechain based on the concept of proof of authority, as it can also achieve sub-second times between blocks. Our design differs in that it’s trustless and completely validated on the root chain through an automated processes, without the need for human intervention.

This model builds on top of battle-tested software, so we don’t have to build our own special purpose clients, network stacks, or nodes from scratch. There will be a number of insurance contracts on the Ethereum main chain to check the correct behavior of the sidechain, including:

Prevent withholding: Make sure that the operator is not announcing blocks to the main chain that it has not broadcasted to the network.

Prevent transaction censorship: If the operator refuses to include a transaction in a block, a user can submit a transaction to the main Ethereum network and request that the transaction be included in the sidechain within a reasonable timeframe.

Carry out block-level verifications: For example, invalid previous block hash, height, or previous state.
Check for invalid transactions: Making sure that all transactions in the sidechain are executed correctly, with storage updates being correctly recorded.

If you compare our model to DPoS (the model upon which EOS is built), you’ll see that we both rely on centralization-ours being more centralized-since operations are carried out by a single node rather than a reduced group. However, by requiring less trust in individuals, our model is more secure. It won’t be possible for anyone to freeze or censor transactions. If the operator ever breaks the consensus rules it will suffer significant financial loss, and the sidechain will halt at the last valid block, allowing all participants to retrieve their funds from the main chain.

We’re currently in the design phase, working through some details of the implementation. We would like to extend our thanks to our friends at Matic Network, TrueBit and Parsec Labs for their invaluable feedback and help.

Get in touch if you would like to collaborate!

Join the conversation on
Discord
Twitter
Reddit
Telegram
Get started with the SDK!

This is an official Decentraland account.
The original published article can be found here on our blog