Interactions

This section dives into how validators interact with the Laïka network through smart contracts. It's intended for developers building validator client and outlines the key functionalities validators

↝ Communication with Smart Contracts

Validators communicate with Laïka smart contracts to fulfill their responsibilities. Here's an overview of the interaction process:

Validator Client: Validator client runs a client application along with a full node that allows connection to the smart contracts and allow reading/writing data to the blockchain.
Contract Interaction Methods: The validator client utilizes functions exposed by the relevant smart contracts (e.g., Validator contract, Fee contract). These functions allow validators to perform actions like:
- Submitting votes on governance proposals.
- Proposing new blocks containing validated transactions.
- Verifying sequencer packages (detailed below).
- Submitting proofs verifying the work done by sequencers (data availability proofs).
Transaction Signing: Validators sign transactions with their private keys before submitting them to the network. This ensures only authorized validators can participate in consensus mechanisms.
Data Feeds: Validator software interacts with external data feeds from Dogecoin Nodes to retrieve information about the Dogecoin blockchain state (e.g., Dogecoin block hash) for verification purposes.

↝ Verifying L1 and L2 Doge Supply

To ensure the integrity of the Laïka network, validators perform a critical check on the total Dogecoin supply:

L1 Supply Retrieval: Using the Bridge contract, validators obtain the total amount of Dogecoin currently locked in the designated Dogecoin bridge address on L1.
L2 Supply Retrieval: Validators query the Bridge contract on Laïka to retrieve the total supply of Dogecoin currently circulating on the L2 network.
Supply Comparison: Validators halt the chain if the L1 and L2 Dogecoin supplies don't match. This discrepancy could indicate a potential security breach or an error in the bridging process. If the supplies do not match, the block production is immediately stopped till the issue is resolved. This allows the chain to be always in spec and provide strict restrictions for the network to be functional.

↝ Verifying Sequencer Packages

Validator client meticulously examines the data submitted by sequencers through sequencer packages. This verification process is critical for ensuring the integrity and validity of Laïka transactions.

Transaction Validation: Validators confirm that the batched L2 transactions within the package are indeed valid and adhere to Laika's transaction format.
Data Availability Proof Verification: This step is crucial. Validators rigorously check the cryptographic proofs generated by sequencers. These proofs demonstrate that the corresponding L2 transaction data is demonstrably available on Dogecoin.
Posting Validator Proofs: Based on the verified Sequencer package, each validator also creates their own ZK Proofs and submit them to the smart contract, this package is then later verified by other validators.

↝ L1 and L2 Data Consistency Check

To ensure the integrity of the entire system, validators perform an additional critical check:

L1 Proof vs. L2 Contract Data: Validators compare the data availability proofs submitted by sequencers with the actual state of the Laika Token contract on L2. Any discrepancy between these data sources indicates a potential issue and could signify:
- Malicious sequencer activity attempting to manipulate data.
- Errors or inconsistencies between L1 and L2 states.

↝ Chain Halting Mechanism

If the verification process (transaction validity, data availability proofs, or L1/L2 data consistency) fails, the validator contract and client takes decisive action:

Chain Halt: The validator contract triggers a chain halt, stopping the addition of new blocks to the Laika chain. This prevents potentially invalid or fraudulent transactions from being processed.
Alerting Mechanisms: Validator client simultaneously sends alerts to network administrators and other validators, notifying them of the issue and initiating troubleshooting procedures.

↝ Pseudocode

Here's a simplified pseudocode example illustrating a validator submitting a new block proposal:

// Validator node connects to Laika smart contracts
validatorClient.connect(laikaNetworkUrl);

// Retrieve a list of validated transactions
transactions = validatorClient.getPendingTransactions();

// Create a new block proposal containing the transactions
blockProposal = createBlock(transactions);

// Retrieve L1 Dogecoin supply from bridge contract
l1Supply = validatorClient.getBridgeTokenSupply(bridgeContractAddress);

// Retrieve L2 Dogecoin supply from token contract
l2Supply = validatorClient.getTokenTotalSupply(tokenContractAddress);

// Halt chain if L1 and L2 supplies don't match
if (l1Supply !== l2Supply) {
  validatorClient.haltChain("L1/L2 Dogecoin supply mismatch!");
  return;
}


// Retrieve the last sequencer package from the contract 
sequencerPackage = validatorClient.getSequencerPackage();

// Verify transactions within the package
if (!validatorClient.verifyTransactions(sequencerPackage.transactions)) {
  handleError("Invalid transactions in sequencer package!");
  return;
}

// Verify data availability proofs
if (!validatorClient.verifyDataAvailabilityProofs(sequencerPackage.proofs)) {
  handleError("Invalid data availability proofs!");
  return;
}


// ---- Validator Generates Proofs ----
// 1. Generate a commitment (public key) for the sequencer package (including transactions)
blockDataCommitment = generateZKCommitment(sequencerPackage);

// 2. Generate a zk-SNARK proof for the knowledge of the block data corresponding to the commitment
dataAvailabilityProof = generateZKProof(blockDataCommitment);

// ---- End of Proof Generation ----

// Add the zk-SNARK proof to the block proposal
blockProposal.proof = dataAvailabilityProof;

// Check L1 data consistency with L2 contract
l1Data = validatorClient.getDogecoinData(sequencerPackage.dataHash);
l2Data = validatorClient.getLaikaContractData(tokenContractAddress);

if (l1Data !== l2Data) {
  handleError("L1/L2 data inconsistency detected!");
  validatorClient.haltChain("Potential data manipulation attempt!");
  return;
}


// Sign the block proposal with validator's private key
validatorClient.signTransaction(blockProposal, validatorPrivateKey);

// Submit the signed block proposal to the network
validatorClient.submitBlockProposal(blockProposal);

// Monitor for block confirmation or rejection
validatorClient.onBlockConfirmation(handleBlockConfirmation);
validatorClient.onBlockRejection(handleBlockRejection);

PreviousValidators NextRewards