On 20th May 2021, The RSK Ecosystem held a community call. The aim of these community calls is to discuss the RSK Improvement Proposals - RSKIPs, get the community involved, gather feedback, discuss the RSK consensus protocol, the formal process for proposing improvements, and the upcoming network upgrades. For more info, read the RSKIP Purpose and Guidelines.
It was live-streamed on several platforms, and we received quite a lot of questions and feedback from everyone who participated! For those of you who missed out on attending it live, we’ll catch you up in this article!
🎥 Watch the Community Call on Youtube (Replay).
🗣️ Propose your own RSKIPs
🔗 Join the Discourse Forum
🔗Join our Open Slack Community and ask your questions in #research-and-innovation
The speakers on this call were:
The live event began with Adrian Eidelman introducing the Community call, he said the idea behind the community calls is to find ways to get people involved in the evolution of the RSK platform and to gather feedback from stakeholders in the ecosystem. The RSK platform consists of several technologies such as the RSK consensus protocol, the client implementation - RSKj, the layer 2 applications and services, the bridges, etc. He noted that the call was not for decision making around the protocol and network upgrades, but that discussion is still ongoing in the community and during subsequent community calls.
Sergio talked about the RSKIP-0, which is meant for proposing changes for the consensus protocols, he explained the process of writing, evaluating, and merging the RSKIPs, and that the RSKIPs started in 2016. He said since then there have been 30 people involved in the writing and evaluating of the RSKIPs, he said there were 244 proposals in which some were abandoned and some were created or incomplete. Out of this number, 137 proposals have been merged, which means it has been analyzed by editors of the repository and found its descriptions clear for the community to evaluate and out of these, 40 proposals have been adopted and activated in the different network upgrades.
The editors of the RSKIPs includes;
Sergio explained the process of submitting a proposal.
This starts with a draft which is a detailed document where you sketch your idea, the draft can be rejected if the community finds it of no value to the platform, or it contradicts some fundamental genesis of concepts of the platform. Or it can be activated - for e.g, if it is a change in consensus or if it is any other change that does not involve consensus, for e.g, a change in the interface of a node or CLI args or packets then it is said to be adopted after several discussions have been had in the research forum, once accepted, it will be implemented in subsequent network upgrades.
The RSKIP has to contain the following sections;
RSKIP-239 and RSKIP-240
Shreemoy Mishra talked about RSKIP-239 - reprice Trie Read Opcodes and RSKIP-240 - Implement Storage Rent in RSK which involves modifying state access costs needed to align transaction fees with resource use (performance, sustainability, and security). These can be achieved by updating fixed costs, new variable costs: storage rent.
RSKIP-223 and RSKIP-224
Sergio Demian Lerner talked about RSKIP-223 - Cumulative Work in Fork Detection Data and RSKIP-224 - Include Uncles in CPV in Fork Detection Data which is related to the security of the RSK platform, he said the hash rate since the inception of RSK has been constantly on the rise and reached 70% of the bitcoin hash rate at a point in time, and presently an average of 65% hash rate of the bitcoin network, which puts RSK as one of the most secure blockchains. He said we should not rest on our laurels but be vigilant and make sure under no circumstances should the platform be insecure. He spoke about the Armadillo project which protects RSK from attacks by providing the community with distributed alerts that can be used by full nodes to detect changes or attacks on the network.
He said there are two types of 51% attacks;
For more details on these, please watch the live recording on Youtube.
Want to champion an RSKIP? Leave a comment on this thread for the next community call!
The following questions were asked during the community call;
Who will pay storage rent for contracts that have many users, such as token contracts or DEXes?
According to the proposal - RSKIP-240, the rent for a contract’s code will be spread across a small number of transactions interacting with that contract. This is something like 2-3 transactions per year. Rent collection is triggered only when the outstanding rent for a state trie node read or modified by a transaction exceeds some threshold. This makes rent collection appear “randomized” across users.
What do you want to discuss in our next community call?
Go to top