Redot #1: Polkadot Restaking and Enabling Polkadot DA Capabilities

Project Name: Redot

Description: Polkadot Re-Staking Layer. Run Polkadot on Bitcoin and use Polkadot as the DA layer.

Milestones: A total of 3 milestones, currently applying for the 1st milestone

Total Amount: 45,200 USD (DOT 6655.868)converted to DOT at ema7 price: 6.791 USD/DOT as of January 31, 2024

ETD: 10 to 12 weeks

Its Use

1. bringing the Polkadot tech stack to ecosystems like Ethereum, Bitcoin, etc., and allowing their developers to use Polkadot. The EVM achieves a winner-takes-all position through its adaptability across ecosystems, and we believe Polkadot's unique secure DA capabilities have the potential to achieve this goal in another way.
2. As one of the final deliverables, we will operate an adapted Polkadot as a relay chain on Bitcoin and use the native Polkadot as a Data Availability (DA) layer.

Brief Description

1. Redot is a re-staking layer for Polkadot.
2. Redot is neutral, allowing for the addition of different types of tasks.
3. We initially support the data availability layer and neutrally support various data availability networks.
4. Validators only need to run a light client, making better use of the idle resources of validators.
5. Redot is designed to approximate the security level of the Polkadot consensus layer.
6. Essentially, Redot is an adapter for the Polkadot consensus layer, endowing it with various capabilities.
7. Capabilities:
   1. Securely and inexpensively synchronize data availability to other L1s.
   2. Data availability persistence, enabling Inscription, Bitcoin L2 to support smart contracts
      1. Bringing an alternative mechanism to Polkadot outside the parachain model, using DOT as Gas
   3. Parachains securely acquire DA capabilities.
   4. Introducing innovative use cases of other models.
   5. Generating additional income for validators.

A common analogy: We can understand the DA layer as a computer's memory, Polkadot as the CPU, and Redot as the motherboard connecting them.

Background and Motivation

Blockchain is essentially about running user-submitted data on nodes and achieving consensus among all nodes on the outcome of that data in some way. As the amount of data submitted by users grows, the synchronization of data between nodes becomes increasingly problematic, with some nodes potentially unable to synchronize, leading to inconsistent results between them. We need a mechanism to ensure that this data can be completely downloaded, which is where the data availability (DA) layer comes into play.

In fact, such mechanisms already exist internally in Polkadot, where the Relay Chain first ensures the data availability of the Parachains. Ethereum has established a tightly-coupled DA layer, and Near has also established a data availability layer. Additionally, there are several third-party data availability layers that have been optimized for either cost efficiency or enhanced security.

The Data Availability (DA) layer is one of the most important areas in blockchain in the coming years. It is widely used in both modular blockchains and sovereign blockchains, concepts that are slightly controversial:

Modular Blockchains

A modular blockchain relies on the security of the settlement layer (L1) and requires verification by this layer. For example, in Rollup designs, data is not stored on-chain, but rather, only the address and commitment of the data is stored in a small space. When running a challenge game, the actual data is sent to the chain, and cryptography ensures its accuracy. However, if challengers cannot download the original data, they cannot run it to detect errors, and therefore cannot initiate challenges. Even a single byte of maliciously hidden data can pose a risk of fund theft.

The settlement layer needs to ensure that data is complete and available when Rollup sends the data address and commitment to the chain. For this purpose, Ethereum has established a DA layer. However, it is prohibitively expensive, leading many L2s to use third-party DA layers, which are usually much cheaper, giving them a cost advantage in competition with other L2s. The trade-off is a sacrifice in security, as Ethereum does not know whether the data in these third-party DA layers is available. Third-party DAs need to cross-chain the data availability to the settlement layer through a DA bridge. These bridges often have only a small scale of validators, making them quite vulnerable for the infrastructure.

Sovereign Blockchains

Sovereign blockchains do not rely on L1 for transaction verification but use L1 as a kind of infrastructure. For example, RMRK can be seen as a prototype of a sovereign blockchain, using Kusama as a message queuing service. We only need to run a simple indexer to ensure security. Although this design is elegant and charming, its fatal flaw is the inability to store large amounts of data or deploy smart contracts.

If we store these data on the DA layer and only save the address and commitment of the data on-chain, we can run a simple indexer to ensure security. We can not only deploy smart contracts but also pack block data directly into the DA layer, giving birth to another mode of blockchain. Many Bitcoin L2s are using this method.

The principle of the DA layer is to expand the data to several times its size, for example, doubling it. Any 50% of the data can recover the original data. We can sample a small section of the data randomly. If the sampling is successful, we have a 50% chance of recovering the data. After multiple samplings, we can ensure that it is probabilistically available. If the data publisher hides the data, it will lead to sampling failure.

However, the data publisher might later reveal the data, posing a challenge to sovereign blockchains dependent on the DA layer. Indexers lagging in blocks might treat unavailable data as available, causing a fork. We need a mechanism to persist the data availability status to ensure all indexers get the same result.

Sharing Polkadot's Security in the DA Layer

Although Polkadot does not have the capability to sample other DA layers, we can solve this with re-staking. Theoretically, attacking the re-staking layer would require attacking the Polkadot network, making the security of the re-staking layer nearly equivalent to that of Polkadot. Redot provides a light client that Polkadot validators can run at a low cost, sample the DA layer, and submit the results to Redot's Parachain, ultimately secured by the Polkadot Relay Chain.

Modular blockchains can obtain DA layer information through Polkadot's cross-chain security capabilities. Sovereign blockchains can directly access Redot's data off-chain to reach a consensus on data availability. We allow all modular and sovereign blockchains the opportunity to share Polkadot's security.

We will also develop a framework for quickly launching a sovereign blockchain. It operates like RMRK, except that the data address and commitment are submitted on-chain. You can launch a sovereign blockchain on Polkadot or Ethereum. As an example, we even run a sovereign blockchain form of Polkadot on Bitcoin, using Polkadot itself as the DA layer.

The above is a very simple description; the actual situation is much more complex. You can learn more in our white paper.

Basic Principles

1. Validators register with Redot to join re-staking.
2. Validators run the operator light client, waiting for distributed key generation.
3. Retrieve tasks to be completed from the parachain.
4. Perform tasks, such as sampling the DA layer.
5. Publish sampling results to the validator network, the coordinator aggregates signatures and submits them to Redot.
6. Wait for the relay chain to include Redot blocks.

Work Completed

Melodot

We have completed the data availability layer product and just launched the development testnet at https://melodot.io/

Redot: PoC

We have completed the Proof of Concept (PoC) work. You can find the PoC in the Redot repository. It overlooks some security issues and tests, but it is functional and has a simplified complete process. It already includes the following modules:

• core-primitives: Implements specific primitives for DKG, threshold signature encryption.
• rc-validator: Depends on the validator network to execute different methods.
• rc-validator-fetch: A module that supports storing and fetching validator information in different environments.
• rc-validator-network: Implementation of the validator network for communication among validators.
• task: Task module for managing different tasks and key rotation, etc.
• validator-registry: Validator registration and deletion module, using OCW for verification.
• redlight: A lightweight client for validators to complete various validation tasks.
• redoxt: A module for communication with the parachain.

Milestones

Redot is divided into three milestones, currently applying for the first milestone.

Estimated delivery: 7 months

Time: 1470 Hours

FTE: 2

Hourly Rate: $80

Total Budget: $117,600

Milestone 1 Redot Parachain

Estimated delivery: 10 to 12 weeks

Time: 565 Hours

FTE: 2

Allocated Budget: $45,200

No.	Name	Description	FTE	Total Hours
0	Docker	Support running Redot through Docker, we will create and publish images to Docker Hub	1	5
1	Documentation	All public interfaces have inline documentation, and we will also provide a guide for users.	1	20
2	tasks pallet	Task-related Pallet, including key initialization, key rotation, task management, task result upload, slash interface, coordinator mechanism, task point settlement.	2	120
3	validator fetch	Supports synchronization of the Polkadot validator set from processes and RPC, compatible with node and operator light clients.	1	60
4	validator pallet	Validator management and reDOT management, including validator registration, status management, Claim, Slash interface, reDOT Staking, relay chain validator status synchronization mechanism, reward collection, etc.	2	120
5	ImOnline	Similar to Substrate's ImOnline Pallet, but we need operators to submit heartbeats through the light client, which requires redevelopment.	1	30
6	application pallet	Pallet for managing applications and fees. Allows registering applications, starting and stopping tasks, deposits and withdrawals. Settles fees at the end of the epoch.	1	60
7	primitives	Improve threshold signature encryption primitives and support the coordinator mechanism. Add other cryptographic primitives needed for Redot.	1	50
8	Validator Client	Improve the identity publishing mechanism of the DHT network, enhance the security of the gossip protocol, add a validator permission system, add coordinator mechanism, coordination of key rotation mechanism, support submitting validator misconduct.	2	100
			Total:	565

further details in our main doc

Milestone 2 Operator Client

Name	Description
Docker	Support running Redot through Docker, we will create and publish images to Docker Hub
Documentation	All public interfaces have inline documentation, and we will also provide detailed guidance for validators to join Redot.
Light Client Refactoring	Refactor the entire framework using Smoldot.
ImOnline	Light client heartbeat module.
VDaser	Abstract module for DAS-like tasks
Melodot Support	Support Melodot's data availability sampling in an embedded manner
Celestia Support	Support Celestia's data availability sampling and fraud proof processing.
Avail Support	Support Avail's data availability sampling in an embedded manner
Frontend	Dashboard for validators, allowing validators to join the network and view network status.

further details in our main doc

Milestone 3 Developer Experience

Name	Description
Documentation	Will provide detailed usage guides for users, including examples.
SDK	SDK to get persistent data availability from Redot, used in nodes including off-chain scenarios. Supports both Go and Rust languages.
DAHub	A way to synchronize data availability to Ethereum or other L1s by directly verifying aggregated signatures. As a cheaper and more flexible alternative to Polkadot cross-chain bridges, this is very useful early on.
Polkadot on Bitcoin	The relay chain client, including Sequencer, Indexer, and XCMHub, provides decentralized indexing services and a messaging hub, and utilizes native Polkadot as the DA layer and underlying consensus.

further details in our main doc

Benefits to the Ecosystem

Unlocking Mechanisms Beyond Parachains

Using Polkadot as a messaging queue service and leveraging the DA persistence provided by Redot will unlock usage models for Polkadot beyond parachains, and use DOT as Gas.

Transforming Polkadot into a Global Consensus Layer

Built on Polkadot's security, the DA capability brought by Redot will turn Polkadot into a global consensus layer for the blockchain ecosystem. This will attract more funding, further consolidating Polkadot's security, thereby forming a growth flywheel.

Parachains as Diversified Settlement Layers

There's a view in the community that Polkadot doesn't need Rollups. We believe this is debatable. Rollups are not just L2; they have a broader design space. You can learn more about this here. Polkadot's parachain mechanism helps give rise to more diversified Rollup design patterns, bringing richer applications and further strengthening the Polkadot ecosystem.

Delivery

1. All code will be made public in our GitHub repository: https://github.com/ZeroDAO
2. Docker images will be published at https://hub.docker.com/repositories/zerodao
3. All Rust code includes comprehensive inline documentation, and each milestone will update the corresponding user guides.
4. All modules have complete unit tests, and Milestone 1 and Milestone 2 include end-to-end (e2e) testing.
5. We will report project progress to the community every two weeks. We have recently set up a forum for community communication: https://forum.zerodao.net/, and you can also contact us quickly on Discord at https://discord.gg/uCQUcd9fk7.

FAQ

Can we directly use Polkadot's own DA?

No, Polkadot's DA serves the relay chain, and it is entirely different from the DA layer available for other chains to use.

Does it affect the security of the Polkadot consensus layer?

There is no theoretical proof or disproof of this. However, the emergence of re-staking is a market-driven behavior, and it's inevitable. We will continue to study its impact on the original consensus layer, both positively and negatively.

Why seek treasury funding?

1. Although Redot is a parachain, it neutrally supports all data availability networks. Not only for Polkadot, but Redot is also undoubtedly a public good for the entire blockchain ecosystem. Moreover, to maintain the purity of the economic system, the team does not intend to reserve a share.
2. We are in a bear market phase and need funding from the Polkadot treasury to kickstart it.
3. As an underlying infrastructure, finding suitable VC funding is not easy. Once Redot is completed, we will have products facing users, and the market will truly intuitively feel our value.

Will you always rely on treasury funding?

No, in the future, development funds will be obtained through Redot's treasury and the ecosystem itself. Regardless, we will continue to move forward.

Can you deliver on time?

We completed Melodot with the funding from W3F, all milestones were delivered on time and received positive feedback. We have extensive experience in developing for the Polkadot ecosystem and data availability layers and value our reputation highly.