Skip to content

Commit a49deee

Browse files
hgergovvikinatora
andauthored
LimeChain's proposal for a research grant for the Polkadot Protocol Conformance Tests RFP (#1950)
* LimeChain's proposal for a research grant for the Polkadot Protocol Conformance Tests RFP * LimeChain's proposal for a research grant for the Polkadot Protocol Conformance Tests RFP * Add lincense and payment currency * Exclude PoC step and adjust effort * Exclude Host API (Storage, Child Storage, Hashing), and Trie Proof Generation. Adapt the effort. Adapt the scope to exclude Host API (Storage, Child Storage, Hashing), and Trie Proof Generation. * Remove the PoC development delivery from the scope Removing the PoC development delivery, it was a leftover from a previous commit when the scope was reduced. --------- Co-authored-by: vikinatora <[email protected]>
1 parent 9950b92 commit a49deee

File tree

1 file changed

+154
-0
lines changed

1 file changed

+154
-0
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,154 @@
1+
# Polkadot Protocol Conformance Tests Research Proposal
2+
3+
- **Team Name:** [LimeChain](https://github.com/LimeChain)
4+
- **Payment Address:** 15reUHgnkE9QeH9zUoduCVYAbksTmQXvpMd6L95rBhTNFuGw (USDT)
5+
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3
6+
7+
## Project Overview :page_facing_up:
8+
9+
This research proposal is in response to the currently open [Polkadot Protocol Conformance Tests RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/polkadot-protocol_conformance_tests.md).
10+
11+
### Overview
12+
13+
Polkadot has made substantial progress over the last few years in terms of client diversification. Currently, there are 4 existing host implementations with varying features and protocol support: [Polkadot](https://github.com/paritytech/polkadot) by Parity, [Kagome](https://github.com/soramitsu/kagome) by Soramitsu, [Gossamer](https://github.com/ChainSafe/gossamer/) by ChainSafe, and [Fruzhin](https://github.com/limechain/fruzhin) by LimeChain. Having a healthy client diversity is beneficial to every blockchain protocol as it becomes more decentralised and less bug-prone. Neglecting these aspects has resulted in halting block production for some blockchain protocols in the past.
14+
15+
The nature of software is such that it's never perfect, and bugs happen. Therefore, multiple host implementations come with a higher probability of implementation-specific issues. It's important for a blockchain protocol that takes great pride in its decentralisation, such as Polkadot, to have a protocol compliance testing suite that verifies the behaviour of each implementation. The more comprehensive the testing suite is, the stronger security guarantees the protocol can provide.
16+
17+
The goal of this project is to prepare for the redesign of the existing [conformance tests repository](https://github.com/w3f/polkadot-tests). Our team envisions the redesigned testing suite to be easily extensible and flexible, welcoming contributors to enhance it with their domain-specific knowledge. Concerns have been raised regarding the "adapter" approach that the existing testing suite has taken and that the chosen language ([Julia](https://julialang.org/)) is out of sync with the one for Polkadot ([Rust](https://www.rust-lang.org/)). This proposal aims to lay the groundwork for resolving these issues by delving deep into the biggest obstacle that stands in the way: finding the correct level of abstraction and tooling that will be the cornerstone for every kind of test scenario.
18+
19+
### Project Details
20+
21+
### A host-agnostic approach
22+
23+
A conformance testing suite should be host-agnostic, meaning that, for the most part, the tests shouldn't be concerned with the specific Host implementation against which they are being executed. The Host exposes several interfaces that enable conformance testing; however, it’s a complex piece of engineering, and there will always be protocols and functionalities without an exposed interface. Moreover, there are integration tests that can't be conducted using an API. These scenarios are as important as the previous ones because the Host can't function properly if the modules don't work seamlessly with one another.
24+
25+
### Host API
26+
27+
The Host API consists of a set of functions that the Host exposes to the Runtime. These functions are used to access external resources for various purposes, including storage access, manipulation, memory allocation, and more. If a method within the API contains a bug, it has the potential to push the Host into an incorrect state transition. Such a scenario could lead to undefined consequences, particularly if a significant number of nodes experience the same issue.
28+
29+
### SCALE
30+
31+
Substrate employs a lightweight and efficient encoding and decoding mechanism to optimise the transmission and reception of data across the network. This protocol, known as the SCALE codec, plays a vital role in serialising and deserialising data. It serves as a critical component for data transfer across the peer network and facilitates communication between the Runtime and the Host. Consequently, the presence of comprehensive tests for SCALE encoding and decoding holds immense significance in ensuring the proper functionality of the Host.
32+
33+
### State Trie
34+
35+
The state trie is another crucial part of the Host. A radix-16 state is the data structure that Substrate uses to store the state of the blockchain. Without thoroughly tested state trie functionalities, the Host may transition to an incorrect state and get slashed if it's a block producer.
36+
37+
### BABE & GRANDPA
38+
39+
[BABE](https://spec.polkadot.network/sect-block-production) & [GRANDPA](https://github.com/paritytech/finality-grandpa) are the bread and butter of the consensus-reaching module for Polkadot. However, finding the right tools and approach to test the block production and finalisation protocols independently of the Host’s environment is a challenge that is yet to be overcome by any team.
40+
41+
### Zombienet
42+
43+
[Zombienet](https://github.com/paritytech/zombienet) aims to be a testing framework for Substrate-based blockchains, providing a CLI tool that allows users to spawn and test ephemeral networks. The assertions used in the tests can include on-chain storage, metrics, logs, and custom JavaScript scripts that interact with the chain
44+
45+
Our team has successfully utilised Zombienet to run PVF conformance tests as part of another W3F grant. This is the reason why we believe that Zombienet has the potential to be the go-to framework for running conformance tests on the Hosts. The research is going to focus on Zombienet, as well as on the new [Zombienet SDK](https://github.com/paritytech/zombienet-sdk).
46+
47+
### Research Scope
48+
49+
The main focus of the research will be on investigating each of the aforementioned protocols and functionalities and how they can be tested in a host-agnostic manner. Based on our preliminary research and the work we've conducted on the PVF conformance testing suite, our team believes that Zombienet can serve as the foundation for the testing suite. The team will examine whether Hosts and Zombienet have the required feature set to support such testing scenarios. If this is not achievable, the team will document the missing components so that they can be identified and potentially contributed in a future proposal.
50+
51+
Our team acknowledges that, for certain Hosts, having the Host API, SCALE, and State Trie as standalone artifacts could be beneficial for Host developers during the early phases of their implementation. However, this proposal primarily focuses on adopting a host-agnostic approach for Hosts that are already functioning with the already existing tests. Depending on the research outcomes, our team may subsequently introduce a new proposal involving the redesign of the conformance repository. In this redesign, the tests would be separated into a standalone artifact and transformed into Zombienet tests.
52+
53+
### Ecosystem Fit
54+
55+
By delivering a research document containing insightful information about the necessary steps to commence the redesign of the Polkadot Conformance Testing repository, we aim for it to serve as a catalyst to initiate the development process
56+
57+
Initially, the Polkadot Conformance Testing repository will be situated in close proximity to the realm of Polkadot Hosts. Its primary target audience will be Host developers seeking comprehensive testing for their Hosts. Other individuals who might find this project valuable include experts from the Polkadot specification team, who can contribute their expertise in specific scenarios.
58+
59+
## Team 👥
60+
61+
### Team members
62+
63+
- Viktor Todorov
64+
- Maksim Dimitrov
65+
- Kristiyan Veselinov
66+
67+
### Contact
68+
69+
- **Contact Name:** Kristiyan Veselinov
70+
- **Contact Email:** [email protected]
71+
- **Website:** [https://limechain.tech](https://limechain.tech/)
72+
73+
### Legal Structure
74+
75+
- **Registered Address:** Bulgaria, Dragan Tsankov 23A, 1113, Sofia, Bulgaria
76+
- **Registered Legal Entity:** LimeLabs Ltd.
77+
78+
### Team's experience
79+
80+
At LimeChain, we possess considerable expertise in developing various tools, including [Gosemble, a framework for building Substrate compatible Runtimes in Go](https://github.com/LimeChain/gosemble), [Fruzhin, a Host implementation in Java](https://github.com/limechain/fruzhin), [a framework for runtimes in AssemblyScript](https://github.com/LimeChain/subsembly), a framework for runtimes in AssemblyScript. On top of that, we’re working on a [Parachain Validation Conformance Testing suite](https://polkadot.polkassembly.io/motion/389), have substantial experience in Rust/WebAssembly developer tooling from [Matchstick](https://github.com/limeChain/matchstick/) and actively contribute to infrastructure projects in Cosmos and Hedera Hashgraph.
81+
82+
### Team Code Repos
83+
84+
- [https://github.com/LimeChain](https://github.com/LimeChain)
85+
86+
Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.
87+
88+
- [https://github.com/vikinatora](https://github.com/vikinatora)
89+
90+
### Team LinkedIn Profiles (if available)
91+
92+
- [https://www.linkedin.com/in/viktor-todorov-8a7434122/](https://www.linkedin.com/in/viktor-todorov-8a7434122/)
93+
- [https://www.linkedin.com/in/chris-veselinov/](https://www.linkedin.com/in/chris-veselinov/)
94+
95+
## Development Status :open_book:
96+
97+
No actual development has been made for this RFP. However, the team has spent a significant amount of time delving into the Host’s specification as part of the Java Host implementation we're currently working on. Additionally, our work on the PVF conformance testing suite has enhanced our understanding of how to address challenging-to-test sections of the code.
98+
99+
## Development Roadmap :nut_and_bolt:
100+
101+
The primary framework under consideration for this research will be Zombienet, as it already provides the groundwork for these types of tests. Each of the steps outlined below will be dedicated to investigating the creation of Zombienet tests for the specified functionalities. The team will also document in the research report the development steps required to enable testing of the specified functionality using Zombienet.
102+
103+
Outlined below are the testing scenarios for each Host module that will be the focus of the research:
104+
105+
1. Host API
106+
1. Trie
107+
2. SCALE
108+
1. SCALE encoding
109+
2. SCALE decoding
110+
3. State Trie
111+
1. Trie encoding
112+
2. Trie decoding
113+
4. BABE
114+
1. Block import
115+
2. Block validation
116+
5. GRANDPA
117+
1. Block import
118+
2. Block validation
119+
120+
### Overview
121+
122+
- **Total Estimated Duration:** 8 working weeks
123+
- **Full-Time Equivalent (FTE):** 2
124+
- **Total Costs:** $49280
125+
126+
### Milestone 1 — Polkadot Conformance Testing Suite Research
127+
128+
- **Estimated duration:** 8 working weeks
129+
- **FTE:** 2
130+
- **Costs:** $49280
131+
132+
| Number | Deliverable | Specification |
133+
| --- | --- | --- |
134+
| 0a. | License | Apache 2.0 |
135+
| 0b. | Documentation | We will provide inline documentation, as well as README file with how the suite can be executed. Additional information will be provided on how to contribute. |
136+
| 0c. | Testing and Testing Guide | Documentation will be provided that showcases how the testing suite can be executed for different scenarios and hosts. |
137+
| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
138+
| 0e. | Article | We will publish an article that explains what was done/achieved as part of the grant. |
139+
| 1. | Host API Research | Research the feasibility of using Zombienet as the framework for executing Host API tests. |
140+
| 2. | SCALE Research | Research the feasibility of using Zombienet for conducting SCALE encoding and decoding tests. |
141+
| 3. | State Trie Research | Research the feasibility of using Zombienet for conducting State Trie encoding, decoding and generation tests. |
142+
| 4. | BABE Research | Research the feasibility of using Zombienet for conducting BABE tests. |
143+
| 5. | GRANDPA Research | Research the feasibility of using Zombienet as the framework for conducting GRANDPA tests. |
144+
| 6. | Research Findings | A research document will be delivered documenting the team’s findings, as well as outline a high-level path forward for the conformance testing suite. |
145+
146+
## Future Plans
147+
148+
Based on the research findings, our team could formulate a proposal for implementing these tests and restructuring the conformance testing suite with the new approach, and/or contributing the necessary features that would enable Zombienet to be utilised for these purposes.
149+
150+
## Additional Information :heavy_plus_sign:
151+
152+
**How did you hear about the Grants Program?**
153+
154+
At LimeChain, we have been contributors to the Polkadot ecosystem for the last 3+ years as we believe in a multi-chain future, based on interoperability and decentralisation. Principles that are built into the core of the Polkadot network. We possess considerable expertise in developing various tools, including [Gosemble, a framework for building Substrate compatible Runtimes in Go](https://github.com/LimeChain/gosemble), [a framework for runtimes in AssemblyScript](https://github.com/LimeChain/subsembly),, and [Parachain Validation Conformance Testing](https://polkadot.polkassembly.io/motion/389). Additionally, we have substantial experience in Rust/WebAssembly developer tooling from [Matchstick](https://github.com/limeChain/matchstick/) and have actively contributed to infrastructure projects in Cosmos, Near, Filecoin, Ledger and Hedera Hashgraph.

0 commit comments

Comments
 (0)