RSK Community Call, May 2021 - Summary
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.
Watch the Replay
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:
- Sergio Demian Lerner
- Gabriella Genovese
- Adrian Eidelman
- Gabriel Kurman
- Shreemoy Mishra
- Brendan Graetz
All about RSKIPs
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.
RSKIP-0
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.
RSKIP Editors
The editors of the RSKIPs includes;
- Diego Masini
- Sergio Lerner
- Julian Len
- Shreemoy Mishra
- Javier Alvarez Cid Fuentes
- Raul Laprida
Submitting a Proposal
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.
Features of a Proposal
The RSKIP has to contain the following sections;
- Preamble: a header containing the meta-data about the RSKIP
- Abstract: A short description of the technical issue being addressed.
- Motivation
- Specification: The technical specification.
- Rationale: The rationale of particular design decisions
- Backward compatibility
- Implementations
- Test cases
- Copyright waiver: All RSKIPs must be in the public domain.
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;
- Revert after confirmation (RAC): Here, a user sends money to an exchange and is confirmed by the exchange, then the malicious user tries to revert the RSK blockchain, and that this attack is very costly because of the time gap involved in getting to the exchange.
- Revert during confirmation: Here, the attacker tries to build a private malicious fork of the blockchain to surpass the honest chain after the transaction has been confirmed, which is less expensive, he said this kind of attack has been implemented against using Armadillo - Armadillo detects the malicious forks by looking at the bitcoin blocks using the RSK tags in the bitcoin blocks and distribute alerts to node operators.
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!
Q & A
The following questions were asked during the community call;
-
How do you pronounce RSK?
- Like you say the alphabets: “are - es - kay”; or you can even use the original name: “Rootstock”.
-
Will taproot help RSK be more efficient and capable?
- Yes! Taproot brings several improvements, such as creating multi-signature scripts that contain a lot more pegnatories, and signers and can be used by RSK to expand the Powpeg, and that taproot is the basis of new changes that will come later to the network.
-
Is RSK built on the Bitcoin network? - Yes!
-
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.
-
Where can I find specific info about the federation bridge? I want to know how many nodes there are, and who is controlling the multi sig
Resources
What do you want to discuss in our next community call?