Beacon Chain Update: Buterin Proposes Changes to Ethereum 2.0

Raul E. Jordan, the Co-Lead at Prysmatic Labs, a team of blockchain developers focused on scaling the Ethereum (ETH) network through sharding techniques, has said that the main idea behind the Beacon Chain is “you’re going to be able to deploy these little worlds that summarize how a blockchain works, how a state transition works, [and] how a smart contract works.”

Jordan, a computer science and biomedical engineering graduate from Harvard University, believes the Beacon Chain design, as proposed by Ethereum Co-Founder Vitalik Buterin, will “make it a lot easier” for blockchain developers to deploy decentralized applications (dApps) on Ethereum.

He explained that software architects will not be required to re-learn new programming techniques in order to launch dApps (when using the Beacon Chain).

Beacon Chain, the “Heartbeat” of Ethereum 2.0

In statements shared with Coindesk, Jordan noted: 

Instead of having one giant machine run transactions one at a time…we can split it up across tons of machines across the world and run them in parallel.

According to Buterin, the Beacon Chain will act as a central blockchain that will coordinate the transactions processed by hundreds of other Ethereum protocol-based chains, referred to as “shards.” The Ethereum platform will transition to this type of network architecture after the launch of major system-wide upgrades associated with Ethereum 2.0, Buterin proposed.

Buterin: Beacon Chain to Store Specialized Smart Contracts

In addition to serving as a coordinator or the “heartbeat” of the Ethereum network, Buterin recently suggested that specialized smart contracts also be stored with the Beacon Chain.

As explained by Will Villanueva, a researcher at ConsenSys, a Brooklyn, New York-based Ethereum development studio, the smart contracts associated with the Beacon Chain are “not analogous to regular smart contracts you would deploy for your application on Ethereum 1.0. Those would live within the shard chains. In contrast, Beacon Chain contracts will represent execution environments or transaction frameworks as a whole.”

Jordan: Developers Will Be Able to Easily Transition to Ethereum 2.0

As noted by Buterin, the latest proposal recommends having “a relatively minimal consensus-layer framework.” This basic framework, Buterin explained, will provide the developers tools and environment needed to create “complex frameworks that give us all of the smart contract capabilities that we need on top as a second layer.”

Confirming that building dApps will not require developers to learn new skills, Jordan said: 

[Dapp developers] don’t have to change much about what they already know.

Notably, Jordan revealed that Beacon Chain contracts may be able to support an execution environment on Ethereum 2.0 that would be quite similar to the Bitcoin (BTC) network’s parameters and development framework.

Making Beacon Chain Contracts Expensive to Prevent Blockchain “Bloat”

In order to prevent network congestion or “bloating”, Villanueva suggested:

In practice, there should not be a plethora of beacon chain contracts. There should only be a few — especially at first.

To discourage developers from deploying a large number of Beacon Chain contracts, Jordan recommended making the process relatively expensive (in terms of gas fees). He explained: 

These execution environments are like their own little worlds that specify everything and ideally they’re going to be really expensive to deploy. Hopefully, tens of thousands of dollars.

On May 27, 2019, Buterin also suggested an update to the Beacon Chain proposal by noting that a “specific class of actor called a relayer” should be integrated into the Ethereum 2.0 upgrade. This will allow platform users to better manage and coordinate transaction fees with the Ethereum network transaction validators (or block producers), Buterin said

Block.one CEO Responds to Coinbase’s Complaints About EOS Network’s Performance

Siamak Masnavi

On Tuesday (February 25), Brendan Blumer, Co-Founder and CEO of Block.one, (the company that develops the EOSIO protocol that powers the EOS platform), responded to Coinbase's concerns about EOS network's "degraded performance levels."

Here is how it all started...

On February 20, Coinbase said via a system status report that "EOS network has degraded performance" and that it was "investigating this issue".

Then, on February 22, Coinbase Support tweeted about the EOS network's "degraded performance levels", linking to the aforementioned status report:

One of the leading EOS block producers, EOS Nation, sent the following reply to Coinbase Support's tweet:

Earlier today, the Block.one CEO sent a series of tweets to explain that the performance problems being experienced by Coinbase were not because EOS was too slow, but rather the opposite, i.e. that the most likely explanation was that the architecture Coinbase's applications for regulatory reporting needed to be improved to so that these applications could keep up with the speed and volume of EOS transactions:

He also said that Block.one is trying to help Coinbase with "their performance issues":