Read on Medium
In the Mail: Questions about Silvermint31 March 2022
Questions from Jeff Joltes (@DevItBetter on Twitter)
In the Silvermint whitepaper you mention that equal stake increases decentralization. While the fixed limit does incentivize whales to run multiple nodes thus increasing the number of nodes on the network, this doesn’t inherently necessitate increased decentralization as the nodes are being controlled by a single entity. How does Silvermint prevent the network from being hijacked by one or more whales with sufficient capital?
In order to stake, you have to purchase the native Silvermint coin. To control the root shard, a whale would have to buy about half of all the coins across the entire network. There is nothing anyone can do to prevent a whale from investing heavily, but this kind of attack is crazily expensive when the network has a value in the 10s of billions of dollars, like Solana ($43B), Cardano ($39B), or Avalanche ($26B). At the very least, trying to buy half of a network’s coins will cause the coin price to double, but in practice it’s likely to be much more difficult than that.
One policy that smaller shards could choose to implement is a joining fee that increases as the number of validators does. A whale might be able to take over the shard, but in the process, they’d have to make the original members rich. If they want to, the original members can then leave en masse and start a new shard together. But this sort of defense won’t be necessary on the main Silvermint shards, assuming we’re as successful as our closest competitors.
Could a shard be hijacked in this way?
All proof-of-stake networks have a limit beyond which a collection of malicious nodes can hijack the network. In Silvermint, this requires:
- control of at least 2/3 of the nodes,
- about half of all minted currency for staking those nodes,
- changing the source code being run on all those nodes to ignore cryptographic evidence of misbehavior by those nodes, and
- hacking the source repository to change the client software that allows clients to verify the cryptographic evidence.
An attacker can temporarily prevent finalization of transactions if they control more than a third of the network. But the remaining validators consider those validators’ stake to be draining away while they’re unresponsive. So when the attack inevitably stops, the attacker loses a significant portion of their stake, possibly gets ejected, and the backlogged transactions begin to finalize. If the attack were obvious enough, it would likely cause the remaining operators to do a soft fork before the attack even ends, slashing the attacker’s nodes.
To cause a double spend to be finalized without a FTM and without losing their stake, the attacker would need more than a third of the nodes and to maintain a complete partition of the remaining nodes for six months so they can unbond. The partition must prevent all communication, even out-of-band communication (like a text, telephone call, or email) between the node operators.
We estimate that the root shard will have at least 2100 nodes, so the ability to slow the network would require more than 700 nodes and complete control would require 1400 nodes. This is in contrast to just a few nodes at any one time in blockchains with leader election.
Requiring node operators to provide a dedicated gigabit internet connection ensures the vast majority of people around the world are unable to participate and help secure the network. The fixed stake required to run a node can also have a similar effect further compounding this issue. Given this, how do you plan to ensure the network remains sufficiently decentralized?
There are no networks where individuals can contribute without trusting a third party. If you join a mining pool, you have to trust the pool operator like Ethermine or Nanopool. If you stake from a third-party wallet, you have to trust the wallet operator like Coinbase.
Just as is done now, smaller investors can pool their resources. But we also support sharding. Shards are not primarily for the purpose of increasing throughput; instead, shards enable node operators to tune their systems to the applications running on them. A defi shard with very low latency requirements has to have fast CPUs and needs all the nodes physically close together due to delays from the speed of light. A land title application may only require a single block per day and could run on cell phones. We anticipate that many different groups will run their own shards tailored to the particular markets they want to serve.
Many existing proof of stake networks support the staking of an arbitrary amount of cryptocurrency. This allows investors of all sizes to earn rewards and in doing so participate in securing the network. Does Silvermint provide a similar mechanism?
Similar to other existing networks, investors with limited resources can pool their funds to stake a node.
How do you intend to maintain low network fees (on the order of a few cents) when the value of the underlying token is dictated by the market? How does your approach to transaction fees differ from existing blockchains such as Bitcoin or Ethereum?
The reason transaction fees are so high on Bitcoin and Ethereum is the scarcity of transaction slots in the blocks. Silvermint has ten thousand times the throughput, so we anticipate that the fees will be ten thousand times smaller.
How are Unstaked Shards secured? Since validators aren’t risking stake, what keeps an Unstaked validator from misbehaving?
There aren’t any unstaked shards. One possible shard parameter is to allow both staked and unstaked validators. Unstaked validators don’t participate in consensus, only in attestation, so they can’t be used to cause a double spend to be finalized. Silvermint also only requires a FTM of staked nodes to finalize a transaction, so they can’t be used to slow down the network by ignoring blocks.
How do transaction fees work in shards? Could you provide some examples of how fees would work in a few simple cases?
Because every validator must always produce a block every block cycle and blocks are not expensive to produce, transaction fees are shared equally by the whole network rather than being paid to individual validators.
Are there any plans to implement a shard that provides EVM compatibility (similar to Aurora on NEAR protocol)?
No. The Ethereum VM requires all transactions to be totally ordered, which is inherently unscalable. Even Ethereum’s own convoluted scaling plans are only for payments, not arbitrary smart contracts. There’s no way to support the EVM and maintain the performance we want. We do, however, anticipate providing an ETH bridge.
Is there any plan to support Solidity or existing smart contracts from other platforms?
No. Aside from the different concurrency models that lead to strikingly different performance, the difficulty of verifying the correctness of Solidity contracts has led to losses of hundreds of millions of dollars, if not billions. We don’t want to make it that easy for users of our platform to write insecure code. Also, perhaps a hundredth of a percent of existing developers have written a smart contract for the blockchain? So there’s no shortage of new developers to attract to our platform.