The network needs to support trustless clients that verify consensus output independently. These “execution nodes” or “light clients” are used by operators who want to track the canonical chain but do not want to store historic data.
All execution results are stored in memory and garbage collected over time.
One use case is creating attestations for bridging.
There is an important consideration to make between “light clients” and “execution nodes”.
Light clients rely on execution results from other nodes. The goal for light clients is to verify execution results without independently executing the blocks themselves. These clients are still secure and are much faster/lighter than “execution nodes”.
Light clients receive and validate consensus output using validator public keys and asymmetric cryptography. If the light client considers the output valid, it makes a request to get the latest header from a full validator node that matches the “parent_beacon_block_root” and “nonce”. These header values correspond to TN consensus output digest and consensus sequence number for the round.
Using a fetched block from a known validator (verifiable on-chain) allows the light client to quickly and efficiently obtain the latest state of Telcoin Network without having to execute every transaction itself.
Execution nodes are stateless clients that independently execute output from consensus. The execution results are not persisted and only stored in memory. The execution node clears up memory over time to prevent exhausting resources. These nodes must download all worker blocks that reach quorum and verify state transitions are valid according to consensus.
By downloading worker blocks as they reach quorum, execution nodes likely have all the blocks they need to execute consensus output. However, the nodes must also have access to download any blocks they’re missing in order to fully execute the output. The missing blocks should be available from nodes that specialize in data availability to limit the number of requests from peers outside the network of nodes that reach consensus.
Ethereum plans to support “stateless clients” eventually, but Verkle trees are a prerequisite for their implementation. Telcoin Network may support these later, but chooses to prioritize a separate node type for data availability.
Validators waiting to participate in consensus must receive output from consensus, download all worker blocks that reach quorum, independently execute all transactions, and store all data. The “non-voting validators” (NVVs) nodes act as an important buffer for data availability and reduce the burden on “committee voting validators” (CVVs), which are responsible for reaching consensus and extending the canonical chain. NVVs support the network as archives for the epoch in which they are not voting. It also supports epoch transitions by ensuring validators are online and ready to participate. The network’s integrity could benefit from NVVs attesting to CVV output, but is outside the scope of this improvement proposal.
Careful consideration is needed to balance the burden for CVVs to reliably broadcasting sealed artifacts to peers within the voting committee and broadcasting sealed artifacts to NVVs for wider network propagation. This is a known scalability issue, but disregarded for now in order to prioritize protocol features over optimization.
The malicious actor creates a fake committee with BLS keys that they control. The validator’s workers are deployed and seemingly running the protocol successfully to produce blocks. However, the network was constructed with an invalid genesis state that benefited the attacker.
In this scenario, the attacker is trying to trick the bridge into migrating funds.
The attacker has funded execution layer accounts (secp256k1) with a generous amount of TEL and they want to bridge off Telcoin Network to Ethereum.
A new validator joins the Axelar network to attest that bridging transactions are legitimate from Telcoin Network to Ethereum. They use a discovery mechanism that has been hijacked by the attackers. They see the malicious committee as valid.
The malicious committee transitions state to show a transaction bridging TEL to Ethereum.
The transactions would not succeed because the locked TEL on Ethereum would not match the request. Axelar would not be able to unlock the amount of funds allocated by the attacker to their account.
Telcoin Network is fundamentally tied to the bridging process. Without a secure, successful, efficient bridging solution, Telcoin Network can’t survive. Bridging is so important, one could argue it’s as important as consensus itself.
Because bridging is arguably as important as consensus, validators should fully support efficient ways to verify state changes. Ideally, anyone can use light clients but the scope of this proposal should prioritize bridging attestation clients.
Validators already produce full blocks for full execution clients, but they should also create “light blocks” with all the information light clients need to verify the next block.
Validator public keys are available on-chain, so any light client with a known block can use that to verify committees and signatures. Once a light client has its “genesis” root (the well-known block it uses as a root to verify future blocks - could also be TN genesis block, but doesn’t have to match), it collects gossiped light blocks to track state changes. All nodes must gossip light blocks to support data availability for bridging services.
Light clients simply collect light blocks from a quorum of validators for the round of consensus.
eth_getProof rpc call sufficient for gossiped blocks without additional light block type?Agreed on aiming for keeping our bridging infra as EVM agnostic as possible since that is how Axelar’s infra is designed to be used. Introducing new RPC endpoints and baking more complexity into the protocol for bridging purposes increases attack surface area and can introduce more tech debt than we’d want to take on, especially considering the likelihood of Axelar pushing updates to their protocol which could include breaking changes that require us to reorganize TN at the protocol layer
The boilerplate voting-verifier setup which we will be replacing with the light client uses the following components:
Ampd is the daemon which attaches to Axelar network and will listen for events (such as those reported by a relay tx) as well as connects to Telcoin Network via RPC where it can verify events on the TN side.
Tofnd is a dependency for Ampd, providing signing capabilities for transactions and batches.
Ampd checks the TN rpc endpoint to verify TN event emission when it is informed of a new bridging request (kickstarted by a the start of a “signing session”, ie a vote). If the bridge request is valid as confirmed by the RPC, then Ampd uses Tofnd to “vote yea” by signing a transaction and submitting it to the voting-verifier. This is the functionality that we will need to connect to the light client’s RPC.
I am still developing my understanding of these things but it really seems like the light client approach is very similar to the voting-verifier, with the main difference being the voting-verifer collects signatures from multiple Ampd+Tofnd instances by weight and uses them to construct a multisig signature on the multisig-prover when the weighted threshold is reached.