The core infrastructure behind ethereum 2.0 might be in for a major redesign.
Dubbed the beacon chain, by ethereum founder Vitalik Buterin suggests radically modifying the blockchain’s role in a new iteration of the ethereum network based on proof-of-stake consensus.
“The idea here is that basically on the beacon chain, you’re going to be able to deploy these little worlds that summarize how a works, how a state transition works, [and] how a smart contract works,” Raul Jordan, co-lead at non-profit Prysmatic Labs, told CoinDesk.
Prysmatic Labs is one of a dozen or so teams building software to support a highly-scalable and energy-efficient version of the world’s second largest based on
According to Jordan, the proposed beacon chain design by Buterin “makes it a lot easier for application developers, people building on [],” to leverage the new network without having to re-learn the parameters of an entirely new platform.
This is welcome to many application developers on the world’s second largest platform, who for years have been anticipating the 2.0 upgrade without fully understanding what it will entail.
“How do we get to proof-of-stake? How do we implement sharding? How do we get there safely? And what does it really mean for the ecosystem and developers in the ecosystem?” asked CEO of crypto application MyCrypto Taylor Monahan in a past interview with CoinDesk.
While many aspects of 2.0 are still highly subject to change and further research, the latest proposal by Buterin suggests interesting new dynamics to simplify how decentralized applications (dapps) are deployed on the estimated $26 billion network.
And it all begins by understanding the beacon chain.
Custom blockchain worlds
The beacon chain is a central that coordinates hundreds of other blockchains, called “shards,” in the envisioned 2.0 network.
“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,” Jordan explained to CoinDesk.
Originally, the beacon chain was to act strictly as the coordinator – or, in the words of Buterin, as the “” – of 2.0, tracking all the data in shards and compiling summaries of that data onto one central .
Now, Buterin has proposed that the beacon chain serve an additional function: to specialized smart contracts called beacon chain contracts.
“These contracts are not analogous to regular smart contracts you would deploy for your application on ethereum 1.0,” Will Villanueva, a researcher for ethereum venture capital studio Consensys. “Those would live within the shard chains. In contrast, beacon chain contracts will represent execution environments or transaction frameworks as a whole.”
In other words, these beacon chain contracts would specify all the rules for computation and smart contract execution including transaction fees, associated gas costs, and more.
“The general ethos of the proposal is to have a relatively minimal consensus-layer framework, that still provides sufficient capabilities to develop complex frameworks that give us all of the smart contract capabilities that we need on top as a second layer,” explains Buterin in his proposal.
Practically speaking, this would mean that dapp developers have the option then to call on a beacon chain contract mimicking the present 1.0 execution environment.
“[Dapp developers] don’t have to change much about what they already know,” highlighted Jordan.
More interestingly, Jordan added that beacon chain contracts could also mimic and create an execution environment on 2.0 with all of the same rules and parameters of the .
For dapp developers, it would be as easy as choosing a different operating system for one’s computer. Instead of booting up a computer with a Windows operating system, one could have the option to leverage a Mac OS or Linux operating system, Jordan told CoinDesk.
He added:
“You can have an execution environment for . You can have an execution environment for . You can basically create your own little custom world and have that be what people transact with.”
Lingering questions
Still, not everything regarding the beacon chain contracts is set in stone.
“In practice, there should not be a plethora of beacon chain contracts. There should only be a few — especially at first,” notes Villanueva about the proposed beacon chain design.
Jordan added that to discourage users from deploying multiple beacon chain contracts and “bloating” the beacon chain, these contracts could be priced at a steep cost for users to deploy.
“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,” Jordan told CoinDesk.
However, both the pricing for contract deployment and the exact parameters for transaction fees based on beacon chain contracts are unclear at this time.
Following up on his proposal, Buterin suggested that a “specific class of actor called a relayer” be introduced into the 2.0 system to help coordinate transaction fees with the “block proposers” of the network otherwise called validators. Since then, Buterin has also released a second to further iterate on the beacon chain contracts idea.
“We need this two-layer structure where there’s one class of node called a relayer,” Buterin mused during an 2.0 implementers call . “The unknown is analyzing the economics of that design more deeply.”
Indeed, the exact mechanics of the newly proposed design of the beacon chain are in the process of further research and discussion amongst 2.0 developers and enthusiasts.
Nevertheless, as noted by Villanueva, the elements of the proposal by Buterin are promising.
Villaneuva writes:
“This approach is a general paradigm shift and may take a bit to really grasp and digest. However, its strength lies in the fact that it provides a high degree of flexibility. It should make it simpler to introduce changes in the future as research continues.”
image via Foundation blog
Published at Sun, 26 May 2019 11:24:52 +0000
