Discussion for PolkaAttest, an attestation appchain that provides cross-chain messaging infrastructure

This is a discussion and a draft for a future treasury proposal, to build an attestation chain, that works as a universal cross-chain messaging solution between existing blockchains and it’s secured by DOT staking.

I would like to start a discussion before asking for treasury funds or starting any development.

This is a public good, a developer infrastructure that makes Polkadot the center of all cross-chain communication.

Development progress: Proof of concept for milestone 1 is under development

Abstract

We are in the multichain era where DApps are scattered around on many chains. Users of the decentralized networks must learn to navigate this landscape to use DApps and a lot of this navigation depends on trusted third parties like a CEX or a centralized Bridge.
The goal is to create a trustless environment, secured by polkadot that facilitates messaging between existing chains.

The problem

Trustless is hard. Centralized infrastructure is a liability, cross-chain messaging UX is bad and can’t be used by novice users. There is no infrastructure that is truly compatible with all chains.

The Solution

ZK proof verification can be the lingua franca of cross-chain messaging. Every smart contract capable chain can verify a zero knowledge proof.

Cross-chain witnesses could observe events and create and confirm attestations and a polkadot parachain developed with substrate could store those attestations and aggregate them with zkp proofs that can be finally used on other chains.

Use-Cases, infrastructure for:

  • Trustless Bridges
  • Multi Chain Tokens
  • Cross chain DEX Swap Routes
  • Cross chain DeFi
  • Arbitrage trades
  • Minimum Extractable Value Source
  • Account Abstraction
  • Cross chain intents
  • Connecting ecosystems
  • Multi-Chain DAO treasury

How it works?

  1. The developer who creates the message sending contracts deploys on Chain A and Chain B. The messages will be passed between these 2.

  2. The developer funds an attestation slot on the attestation chain with DOT.

  3. Witnesses stake DOT to operate, in-case of malicious behavior their stake is slashed.

  4. Witnesses watch Chain A for message events

  5. Witness submits attestation to the chain and confirms existing attestations

  6. Witness claims reward when attestation is confirmed to be valid.

  7. Signed attestations are aggregated into a Groth-16 proof

  8. Proof is verified on Chain B.

  9. Supports account abstraction with trustless Snarks. Optionally Chain B can reward valid proofs with fees to incentivize message relaying.

  10. User sees his interaction result on Chain B

Benefits to the Polkadot ecosystem

A new use-case for DOT
DOT as “gas” for cross chain messaging infrastructure
Onboards developers from other chains
Places Polkadot into the center of the cross-chain blockchain world

How the cryptography works?

Witnesses use EDDSA using Poseidon Hash which is verified using ZKP (circom EDDSA)

When staking, claiming rewards, and submitting attestations and confirmations, the withesses sign messages using EDDSA which is verified on the attestation chain using Groth-16.

The attestation chain stores the leaves of a Merkle Tree of Witnesses who are allowed to use the attestation slot.

The developer who uses the messaging infrastructure, must store the merkle root of the allowed witnesses on the Chain B contract for the final message verification.

The witnesses allowed to attest are verifiable on both the attestation chain and final message destination chain.

The Groth-16 proof to the message destination verifies N of M Witnesses agree on the message validity and the witness public keys are in the merkle root.

This creates a trustless cross-chain messaging infrastructure, secured by DOT staking, that works with all smart contract chains supporting Groth-16 verification.

The development work that needs to be done

  1. Two Circom Ciruits for ZKP
  • Verify an EDDSA signature
  • Verify multiple EDDSA signatures and check if they are stored in a merkle root
  1. Messsage emitter interfaces developed in multiple smart contract languages (Rust, Solidity, Move, FunC)
  2. Witness CLI and Daemon developed using NodeJs and CircomlibJs.
    • Contains a Wallet for staking and claiming rewards
    • EDDSA signatures with circomlibjs
    • API to watch origin chains and submit attestations to the appchain
  3. Attestation Parachain for Polkadot
    • An AppChain
    • Uses DOT as a token
    • Provides Configurable Attestation Slots
    • Developers using it need to fund witnesses with DOT
    • Witnesses stake DOT (POS) and claim rewards
  4. Destination Smart Contract Verifier (Rust, Solidity, Move, FunC)
  5. Trustless relayer written in nodejs with it’s code reusable in the browser for manual use. (E.g: Instead of abstractions, the user needs to interact twice)
  6. A custom chain explorer that will provide insight into the appchain and allow full interaction with it, and shows the transactions on both the origin and destination chains.
  7. Developer Documentation with examples and 1 click deployments

Cost Estimates

The costs are based on development time which is async.
The hours will be tracked and linked to commits, which can be done using google doc or notion.

The estimated time to reach testnet is 1 year.

This is full stack cross-chain blockchain development, using Rust, circom, !Ink, solidity, move, FunC, and NodeJs, and Golang, HTML, CSS, TS

Development cost:

128USD/hour + 42% tax (based on my current location in Scandinavia)

Price: 1 year with 40 hour weeks is $245 760 USD + $103 219 USD in legal fees

Final Requested amount for 1 year is : 348 979 USD

The development costs could be paid out in milestones covering 3 months of work, then the testnet will be completed using 4 milestones.

Development will employ 1 main full stack developer and contractors for delivering front-ends.

After the first milestone is funded, documentation about company formation and the employed team will be provided.

First Milestone

  1. Development of the Circom circuits
  2. Witness CLI and Daemon
  3. Development of cross-chain message formats for origin and destination chains

Mainnet costs:

The audit costs and the hardware costs to run the nodes will be calculated after testnet. Multiple auditing firms should be contacted before mainnet deployment for a quote.

There must be also two Trusted setup ceremonies to create secure ZKP before mainnet launch, which is an added cost.

Maintenance:

With less development frequency, 1 year of development fees should cover a longer period. It should be paid out in 3 month milestones, just like delivering the testnet funding.

Marketing strategy

This is an infrastructure aimed at developers, it’s direct use is abstracted from regular users.
The chain provides no investment or new tokens and needs to be marketed only to developers.

Hackathons and bounties would incentivize developers to build on this infrastructure.

Example: 500 - 1000 USD bounty for developers building on top of the network and 500$ in DOT deposited into the attestation slot to fund the witnesses.

Let me know if there are any questions. Feel free to chip in with ideas.

I would be really happy to receive some feedback.

Here is some of the ongoing work:

Here are the circom circuits for the zkp used for this project

The first repository contains the message format, message signing and verification.

The second repository contains bulk signature verification for witnesses for confirming messages and the merkle tree implementation to verify signer authenticity.

These are the underlying cryptography implementations that make cross-chain witnesses and attestations verifiable on any chain that supports zkp.

How it’s supposed to be used?

A witness observes a message emitted by an origin chain and signs it.

After 10 witnesses confirmed the message via signed messages, their signatures can be rolled up into a single proof which can be used on a message destination chain.

The first proof is to create a single confirmation of a message.

The second proof is to bundle ten confirmations together, and checks if the signers are allowed to confirm the message via merkle proofs. This final proof can be used to deliver the message to the destination.

1 Like