Waku as sovereign chain

[alrevuelta]

Every decentralized protocol can be designed as:

• 1) An application built on top of an existing blockchain, that guarantees that a given state is modified according to some rules and preserved. Eg, via a smart contract in Ethereum.
• 2) A sovereign chain, with their own set of validators and consensus, crafted ad hoc for its purpose, without depending on 3rd party blockchains.

Before the introduction of RLN, waku was an isolated protocol that didn't require any external interactions. But with the introduction of RLN as an smart contract deployed on an existing chain (Ethereum), it started becoming i). This issue discusses the possibility of waku becoming ii), its own sovereign chain with its own nodes, consensus, state, etc.

The current approach i) has the following pros:

• Leverages an existing infrastructure with thousands of nodes and high-security guarantees, meaning resilient against attacks and truly decentralized.
• Simplicity, since the only development required is a smart contract (RLN by now)

But it has some cons:

• Introduces an external dependency outside of the waku ecosystem.
• A node wanting to sync the RLN contract state, has to sync millions of irrelevant transactions not belonging to waku. This massively increases the requirements of running a waku full node (waku node + Ethereum full node). In other words, you must sync a state of 500Gb and you are only interested in 60Mb.
• Fees (even in L2) are higher since waku users compete with other users doing "swaps" of monetary value, willing to pay way more than waku users.
• Paid fees (to validators) go outside of the waku ecosystem.

Switching to ii) would be non-trivial, since it will imply:

• Waku nodes are no longer just relay/store/lp/filter nodes. They now have to reach consensus on a given state after executing a given code (eg RLN insertion). This is no longer delegated to another chain.
• Said nodes would need some stake, assuming we follow a PoS approach. A token would be needed to transact in this new ecosystem. It will be used reward/penalize given behaviour. Waku nodes now need to reach consensus on a state, and keep moving the chain forward. Waku would be no longer a best-effort message delivery. Nodes will have incentives to move the chain forward.
• Full waku nodes no longer need to store the state of a 3rd party chain. No more storing 500Gb of Ethereum transactions.
• All value stays within the waku ecosystem, eg tx fees go 100% to waku node operators (aka validators?).
• Having consensus between waku nodes, could open up new use cases, eg consensus in store protocol?

Some unorganized thoughts:

• Developing ii) from scratch would be a no go, at least by now, but there are some SDKs that we may explore, like Cosmos SDK and Substrate (Go and Rust respectively). They provide all the heavy lifting like EVM compatibility, consensus, etc.
• Projects like dydx evolved from i) to ii), being now a cosmos chain with its own set of validators.
• In the case of tendermint BFT (cosmos SDK), validators are restricted to a few hundred. Something to take into account.
• Nomos may be working on something similar.
• Incentives may be easier to solve with ii)

[chaitanyaprem]

Completely agree with you thoughts on this and it makes sense to not depend on an external chain which has a huge state to sync and maintain for just running a node that does p2p communication.

• Waku would be no longer a best-effort message delivery

Not sure how this would be gauranteed though. Maybe i am missing something here. RLN state sync would only happen as new users onboard the network and that will only gaurantee that state is synced across not messages that are delivered by each node right.

[alrevuelta]

Waku would be no longer a best-effort message delivery

Not sure how this would be gauranteed though. Maybe i am missing something here. RLN state sync would only happen as new users onboard the network and that will only gaurantee that state is synced across not messages that are delivered by each node right.

Let me rephrase. I meant that if we introduce consensus in waku, not just for rln but for other (to be explored) things, the guarantees could be higher. Having consensus allows to better measure the actions that you want to reward/penalize. So these actions would be backed by onchain incentives rather than being just "best effort". Note that I'm referring to the "actions" beyond the current slashing with RLN.

[adklempner]

If a sovereign chain is used, what currency would be used for purchasing RLN membership?

[mart1n-xyz]

Some notes from the token economics perspective:

• introduces a way for 3rd party services to live entirely in the Waku Network with tailored guarantees for their products and micropayment infrastructure
• will make incentivization indeed easier as there can be a reliable record of desirable events
• can evolve into a generalized validation-as-a-service network (not only RLN membership but other on/off chain events), perhaps following the model pioneered by former Keep Network, now Threshold Network
• is compatible with the Waku Network of Networks vision
• Nomos zones are indeed a good fit for this but in this scenario, there are still frictions: WN nodes would either need to be Nomos validators (with a Nomos stake) or give some incentive to a sufficiently decentralized set of Nomos validators to validate this zone.

[ABresting]

few thoughts:

1. What are we trying to solve here? Maybe Higher RLN fee, competing block space, 3rd ecosystem dependency... Users prefer current scenario coz it comes with added legacy (BTC, ETH) L1 security, if we also deploy RLN SC on Polygon or Arbitrum, IMO it still would be ETH L1 > sidechain/L2. So with sovereign chain are we helping the users or doing this for us?

Having consensus allows to better measure the actions that you want to reward/penalize.

Can we first quantify this somehow? i.e. Having sovereign chain has better guarantees than WN sync'ing with a cheap, MINA style state chain?

[fryorcraken]

Projects like dydx evolved from i) to ii), being now a cosmos chain with its own set of validators.

If we see this as a potential path. Assuming that using Nomos is the final goal. Then it would be good to understand how much of detour we take by having RLN smart contract on an existing L2.

• How many assumptions are we able to validate by having a smart contract?
• How much work that would be thrown away by using a smart contract now, assuming own chain later?

From a product/developer experience/user experience perspective, we still have open problems. Let's say a dapp dev has a smart contract on Arbitrum and we deployed RLN on OP. It means that users or dev need to interact with both chains already, with potential bridging issues/friction. Using a sovereign chain does not seem to make it worse here. Could potentially make it better if we leverage Waku node to provide Web3 RPC service.

[alrevuelta]

How much work that would be thrown away by using a smart contract now, assuming own chain later?

Depends on many things, but most likely with our own chain, we would reuse everything, but deploy it in our chain instead. But ofc, the difficult thing is having our own chain.

So by now, i would leave this idea as a thought, not affecting the current RLN plans.

[fryorcraken]

Another con of a sovereign chain is that it reduces the composability of Waku smart contracts. Having said that, it is not clear if if's a demanded feature. Will projects integrating Waku want to compose with the Waku smart contracts? E.g., automatically allocate memberships of "service credits" based on onchain events or data?

[corpetty]

I've recently had a conversation with @jm-clius about "consensus" at various layers of Waku w.r.t. message reliability. I'd suggest we have a joint talk with the Nomos team about this at the upcoming All-Hands in Athens. A few notes:

• Consensus does not have to be tied to a chain. It is possible to just perform consensus on a subset and move on without the weight of a chain and its history. My suggestion to @kaiserd, @jm-clius, everyone else is to explore Avalanche (and our variant Claro) for this. Many lightweight and efficient (and parameterizable) instances can happen at once. It's interesting that the current research route HEAVILY overlaps with this idea. Ask me or @jm-clius for more links and information if interested.
• The chain decision is tightly coupled with the "payment scheme" and composability, not necessarily consensus. It is possible to run multiple dependent up on the requirements of the thing being decided on and what downstream applications rely on it.
• I think there is room to explore multiple paths here, with different subsections of the network relying on different forms of consensus/payment/validation/etc

[SionoiS]

Tangentially, can we not build some kind of L2 since nodes agree on ordering of messages by virtue of using RLN?