Bedrock

Cryptarchia

• Slash double-signed blocks (ie two blocks using the PoL, which is a byzantine behavior that we can slash).
  • Mechanism: not adding the evolved commitment. PoL consumes one coin by revealing the nullifier and produces a new one by publishing a new commintment of the same value. If you don't add the new committent we have slashed the owner of that coin.
  • This should be possible only during the slot, to avoid reorgs later on caused by byzantine nodes that release the second block invalidating the first one.
  • This can be achieved by showing a proof of the two blocks and instead building on the parent. This cannot be done if the offending block has already a child block, in which case the canonical fork-choice longest-chain rule prevails.
  • This operation adds + 1 to the length of the fork, to compensate for the potential loss of that the executor of the slashing would incur by not building a longer fork (ie next leader would not have a way to select this honest fork from an equally-long one, so we are making this one 1 block longer virtually as if the faulty block was included)
• Epochless Crytparchia
  • Since our new randomness is derived from the commitment set including the latest proposal in the fork, we can get rid of epochs for the PoL. The question then is if we can get rid of them completely.
  • Epochless cryptarchia probably 6-10x's our block lookback buffer, it might be fine though since you probably just need to keep block headers, not full blocks.
• Prove evolution of epoch nonce $\eta$ in PoL.
  • currently, PoL exposes some randomness $\rho$ that is used as input to the epoch nonce $\eta$ derivation. Instead of making every validator maintain this epoch nonce, we could instead have the leader prove the evolution of $\eta$. This has a number of benefits:
    • Since $\rho$ is derived from the leaders note, evolving $\eta$ in STARK would remove the risk of exposing some linkable identifier
    • Validators become even more stateless as they would not have to maintain the epoch nonce state variable
  • the drawback here is that it forces PoL to being proved after the parent block has been revealed. This squeezes the leader to try to build a block and proof leadership in the short window after it sees the previous block. Proof times are not good enough right now to support this.
• Support Adaptive Corruption Resistence
  • Currently, PoL doesn’t provide any adaptive adversary resistence. In the case where a node is corrupted, the attacker is able to regenerate new PoL for all the previous won slots, enabling potential attack vectors to rewrite the chain.
• Multiple Concurrent Proposers
  • Instead of coming to consensus on an ordered block of transactions from a single block proposer, each of the K proposers propose a set of transactions at the same time. The protocol then aggregates these proposals using a common subset primitive (or a similar algorithm, this is an active area of research), yielding an unordered set of transactions which are to be included in the block.
  • MCP solves the problem of censorship-resistant inclusion, achieving the goals of Inclusion Lists in a more natural way. The output is an unordered set of transactions, so it does not solve the problem of reordering. That will be the responsibility of the execution layer.
• Distributed Block Building
  • Under a PBS paradigm, multiple builders will contribute to the block, which the proposer is enforced to propose
  • Another option is to have multiple blocks merge, either by producing intersection or union.
• Deterministic Ordering
  • To do this, we must delay the calculation of the state root to the next block so that the execution layer has time to implement a deterministic ordering rule.
  • Once it has the transactions, the execution layer has a new important job: figuring out how to order them. To do this, we need to select a deterministic scheduling rule.
  • This deterministic ordering probably should introduce randomness from the previous block, to make the order unpredictable until its execution in the next block.
• Prevent Tagging Attack through DA
  • Forcing all mantle transaction data to go through DA gives us the leader the confidence that a large fraction of the network has seen this transaction and will not be tagged by including it.
  • Important that the transaction that goes on chain with a reference the DA commitment does not include some additional user chosen data that could be used to tag a leader
• Improved incentives for transaction inclusion for leaders
  • Private Proof of Stake over transparent UTXOs brings a problem of transaction inclusion incentives. Since we need to give the same rewards to all block proposers for privacy reasons (to avoid tracking via reward distribution who was the proposer), we bring two pernicious side effects:
    • Lazy leaders (potentially including nothing)
    • Censorship resistance reduction (even in an MCP setting, now those who would be willing to take the risk, might not take it because there is no incentive)
  • The objective is to find a solution to incentivize the inclusion of ALL mempool transactions that doesn't break privacy. Some ideas include:
    • In an MCP setting, cryptoeconomic games to make all validators propose as much as possible.
    • Encrypting/hiding the tx, by using a mechanism similar to encrypted mempools, whereas transactions are threshold-encrypted and decrypted immediately after inclusion.
• Total Stake Inference: Uncle References To Improve Measurement of Slot Occupancy Rate
  • Total Stake Inference relies on measuring the slot occupancy rate to infer the total active stake, we do this by measuring the honest chain growth rate during a fixed period. Since Cryptarchia is forky, those forks contain blocks that are not on the honest chain and so do not contribute towards the empirical measure of slot occupancy. In simulations we’ve found that this undercounts total stake by ~15%.
  • If we had uncle references, that 15% error goes away since all nodes can now count blocks that are off of the honest chain.

P2P Network NAT

• Allow Private nodes to be discoverable

  • A Private node must:
    • Run a Circuit Relay v2 client, and advertise, via Identify, the support for the following protocols:
      • /nomos/circuit/relay/0.2.0/hop
      • /nomos/circuit/relay/0.2.0/stop
    • Secure at least one reservation at a Circuit Relay server in order to join the P2P network. Once a reservation is secured, the node must both listen on and advertise its relayed address via the Identify protocol. A reservation at a given Circuit Relay server is automatically attempted by the libp2p stack when a Private node tries to listen on the address of the Relay server. A successful reservation is then automatically renewed by the libp2p stack as long as the connection is still open.
  • A Public node must:

    • If enabled via config, run a Circuit Relay v2 server and advertise, via Identify, support for the following protocols:

      • /nomos/circuit/relay/0.2.0/hop
      • /nomos/circuit/relay/0.2.0/stop

    • Add a Private node to its discovered nodes set, if the Private node has secured a Circuit Relay reservation at the Public node’s Circuit Relay server. The Private node should be added with the following relayed multiaddress: /{public_relay_ip}/udp/{port}/quic-v1/p2p/public_relay_peer_id/p2p-circuit/p2p/{private_peer_id}

      If the Private node loses its reservation at the Circuit Relay server, the above relayed address should be removed from the discovered nodes set.

• Dialing Private peers

  • A Private peer can only be dialed by other peers if it has at least one valid reservation at a Circuit Relay server. Its addresses then have the following relayed multiaddress form:

    /{public_relay_ip}/udp/{port}/quic-v1/p2p/{public_relay_peer_id}/p2p-circuit/p2p/{private_peer_id}

  • The peer discovery protocol must provide information about publicly reachable addresses of peers. When dialing a peer, the libp2p stack will automatically determine if the connection should be direct or relayed, depending on the address of the dialed peer. If the dialed peer is a Private peer and both peers advertise support for the DCUtR protocol via Identify (/nomos/dcutr), NAT hole punching will be automatically attempted by the libp2p stack.

Mempool

Transaction fetch protocol

When transaction hashes are evicted from the mempool, the corresponding transaction bodies are removed from storage to prevent unbounded growth.

• Problem: If an evicted transaction later appears in a valid block, the node cannot validate that block because it no longer has the transaction data.
• Solution: Implement a peer-to-peer fetch protocol to retrieve missing transactions:
  1. Block validation fails due to missing transaction.
  2. Request transaction from peers using the transaction hash.
  3. Peers respond with full transaction data (if they have it).
  4. Retry block validation with the retrieved transaction.