Skip to content

Scaling projects and proposals and other crypto infrastructure projects

James Ray edited this page Mar 14, 2019 · 3 revisions

Contents

Of all the crypto projects I've looked into so far, including Ethereum, Holochain appears to be the most useful.

See also these scaling proposals.

Alternative approaches to scaling other than sharding include state channels, side chains, multi-chains and off-chain computation. Projects are included here in this summary spreadsheet by the Web3 Foundation. Parity Substrate is another project. Other designs and sources of inspiration include:

Potential sources of inspiration / other projects include:

Team Rocket with Snowflake to Avalanche

Snowflake to Avalanche: A Novel Metastable Consensus Protocol Family for Cryptocurrencies: it's a probabilistic Byzantine fault tolerant (BFT) consensus protocol that is synchronous on paper, but has been developed on a real internet (which is partially synchronous at best).

Ziliqa

Ziliqa: a PoW sharded architecture consisting of a dataflow smart contract layer, and 5 other layers. Uses the EC-Schnorr multiginature signature scheme. However, RANDAO is preferable to aggregate/multisignature schemes since it is not prone to a 51% attack. Also uses committees, as is planned with Dfinity and Ethereum, although here the committees manage how miners are assigned to shards, whereas in Ethereum that is the task of the beacon chain and the sharding manager contract on the main chain. Uses PBFT consensus, which doesn't seem to be as good as Casper FFG, which is also used with PoW.

EOS

EOS: has a DPOS (delegated proof of stake) protocol. It experienced a liveness fault [1] and locked accounts to prevent theft just days after launch (which has spillover effects to other cryptocurrencies if exchanges decide to socialize losses from EOS, e.g. by freezing accounts of EOS and other cryptocurrencies and declaring bankruptcy, which in turn has legal implications [2]). It is controlled by a relatively centralised server and cartel of 21 block producers. It does not have a provably correct-by-construction, formally verified consensus protocol. It is very expensive with deposits instead of fees (deploying Cryptokitties on it at it's peak would cost about $1.5b in staked deposits) [3, 4]. You need to pay to create an account, need EOS to buy RAM in order to make transactions. Need to stake EOS for CPU and network resources (IMO this is a necessary con, since without incentivizing resource use, a tragedy of the commons arises; see e.g https://eips.ethereum.org/EIPS/eip-908).

Bitcoin and Bitcoin Cash

Both lack a Turing complete language to use for stored procedures (more commonly known by the less appropriate name of smart contract) and decentralised apps (dapps)

Regarding Bitcoin Cash, doubling the block limit does not seem like a good idea, as it makes the network more centralized. The roadmap also includes "adaptive block size (market driven growth to 1 TB). Again this is not good for decentralization and security. It's uncertain how Bitcoin Cash and Bitcoin are going to be sustainable by having low rewards and high fees (and no gas limit, which is not good for pricing economics; FMI see DRAFT: Position paper on resource pricing (https://ethresear.ch/t/draft-position-paper-on-resource-pricing/2838)). Both will continue to use PoW which is bad for scaling, energy consumption, decentralization and security. Bitcoin using Lightning Network isn't sustainable long-term (like other L2 solutions); FMI see ethereum/wiki (https://github.com/ethereum/wiki/wiki/Sharding-FAQs#how-does-plasma-state-channels-and-other-layer-2-technologies-fit-into-the-trilemma).

Early research

For precursor research scaling ideas, see para 2. here (see the links to hypercubes and Chain Fibers—a precursor to sharding, as well as hub-and-spoke chains).

Clone this wiki locally
You can’t perform that action at this time.