SUAVE Consensus

SUAVE
, ,
1

Edit: Note, this discussion precedes the current specs and those should be referred to for concrete details.

As far as I know, there has been little thinking that has gone into this. General research would be appreciated.

Prompts/questions:

  • What consensus algorithms are options for us given that we require low latency (maybe responsiveness?)? What other properties would we want.
  • The main functionalities of SUAVE consensus nodes we have listed are maintaining the mempool, maintaining attestation/mempool DA layer and maintaining SUAVE global state. Should these be separated out? Which protocols serve which needs better.
  • What are our geographical decentralisation requirements? (@phil)
  • We likely need single-slot finality so that we can ensure kettles are running on the correct state. What is the impact of forks on the network?

Candidates off top of head:

  • Multiplicity
  • Narwhal and related (?)
  • Themis (added benefit of allowing applications to attempt FCFS if they really want to try)
1 Like
2
  • What consensus algorithms are options for us given that we require low latency (maybe responsiveness?)? What other properties would we want.

A couple of questions on this:

  1. Is the idea here that pending TXs would remain in SUAVE mempool unless they are included in an Ethereum block? If so how is that exactly checked, by an Ethereum lite client inside the SGX?
  2. Say block time on SUAVE and Ethereum are 1s and 12s respectively. 12 TXs (t1,t2,…,t12) hit SUAVE uniformly with one second difference (1 TX per second). In this case would 12 SUAVE blocks be merged into a single ETH block to be relayed to the ETH proposer (validator)?
  3. Assuming block builders in SUAVE receive gas payments / bids, is a block builder better off waiting to build a block until ETH block info is being relayed (that way possibly the SUAVE builder has the highest number of SUAVE TXs to put in a block and maximize revenue)?

What are our geographical decentralisation requirements?

From experience with Secret Network validators who ran SGX - most validators used IBM Cloud and Azure. In mid-2021 there were a handful data centers that weren’t really globally decentralized.

Also I remember back in 2021, Intel had plans of discontinuing SGX for personal devices and optimize SGX use in data centers.

1 Like
3

Yes, messages sent to kettles (potentially with Eth TX as payload) may not be executed immediately. It will be necessary to run an ETH light client in the TEE, but I’m not seeing immediate connection to the mempool here. Are you asking how the nodes determine which messages can be discarded as the payloads have already been executed?

So the above needs a bit of an update. There are three ways of interacting with suave:

  • interacting with suave chain, these are standard transactions which can change contract state
  • directly with kettles. The outcome of this will be to produce some (potentially encrypted) output. Time is continuous in this setting.
  • via a consensus mechanism (“bulletin chain”) for censorship resistance. The idea is that encrypted messages are attested to by a consensus set so that kettle operators cannot attempt to censor inputs like quotes to fill an order as contracts can express logic like “this order is only executable if bulletin chain block at height H has not been ingested”)

Block building hasn’t been completely scoped out (maybe @dmarz has something to add here?) but you can think of blocks just being another kind of output from the kettle decoupled from SUAVE chain blocks

IUC, yes.

Thanks!!
From looking at phala data, it seems like decentralisation has improved.

1 Like
4

Yes, messages sent to kettles (potentially with Eth TX as payload) may not be executed immediately. It will be necessary to run an ETH light client in the TEE, but I’m not seeing immediate connection to the mempool here. Are you asking how the nodes determine which messages can be discarded as the payloads have already been executed?

Yes that’s what I was curious about. I guess light client in the TEE solves this

I have some questions about the SUAVE chain interactions:

Is it fair to assume that this is just like any blockchain mempool with the exception that suave TXs also have a confidential compute request? I read somewhere that suave TXs need to specify a Kettle address. So is it fair to assume that not all kettles/TEEs will pick up all TXs from the suave chain mempool?

Similarly, is the reason why we care about censorship resistance that suave TXs specify a kettle address rather than all kettles doing the computations and forming consensus on the results on the suave chain?

1 Like
5

FYI there’s an update on consensus here

So is it fair to assume that not all kettles/TEEs will pick up all TXs from the suave chain mempool?

Yes!

confidential compute request

this is the name we use for messages sent by users directly to kettles as opposed to transactions which go to chain. Rigil is a bit different from the end design in that users send compute requests and then these trigger transactions being forwarded to the chain.

Similarly, is the reason why we care about censorship resistance that suave TXs specify a kettle address rather than all kettles doing the computations and forming consensus on the results on the suave chain?

We care about censorship resistance because applications like auctions happen in kettles and kettle operators can filter traffic at the network layer, blocking bids from entering the auction.

1 Like