KLYNTAR Docs
TwitterDiscordSiteGitHub
  • Klyntar project intro
  • Project litepaper and main features
    • About project
    • Unique architecture - take the best from L1 and L2 chains
    • Multilevel sharding and modularity
    • Multistaking - native liquid staking, multichain multiasset staking and much more!
    • Checkpoints mechanism
    • Advanced cryptography - zk, mpc, fhe, post-quantum and much more!
    • Virtual machines - EVM, WASM, containers and much more!
    • Parallelization
    • Abstractions - for account, storage and chain
    • RWX - codeless smart contracts for real world usage
    • Unique shared security model
    • Mutations - add new functionality and improvements simple and fast
    • Forgetfulness - a blockchain cleaning mechanism
    • Low validator requirements and mobile validation
    • AI layer
    • Quantum future
    • Bring your social value to alternative economy
    • Ecosystem & Future services
  • Other resources & links
    • Official links
    • Brand assets
    • Partnerships
    • Tokenomics
    • 📚Glossary & Taxonomy
      • Our repositories and codebase
      • Architecture
      • Types of transactions
      • Types of accounts
      • Virtual machines
      • Consensus
      • RWX codeless smart contracts
  • Wallets usage
    • Wallets to work with WVM and native environment
    • EVM compatible wallets
  • build core and join network
    • ☁️Build the core
      • Build process
    • 🕸️Networks
      • Testnet
        • Your own private testnet
          • Netrunner
          • Netrunner and PM2
        • Public testnets
          • Testnet faucets
          • Setup testnet node
      • Mainnet
        • Setup mainnet node
    • 🪙Staking
      • Default staking
        • Staking
        • Unstaking
        • Native liquid staking
      • Multichain multiasset staking
        • Supported networks and tokens
        • Full list of supported assets
        • Work with native coins
        • Work with ERC-20 tokens
        • Work with ERC-721 tokens
        • Other
          • Work with Bitcoin, Litecoin and Doge
          • Work with XRP network
          • Work with TRON network
          • Work with Solana
        • Social value points
          • Telegram
          • Github
          • Instagram
          • Facebook (Meta)
          • YouTube
          • LinkedIn
          • Twitter
          • Discord
          • TikTok
          • Spotify
          • Hirsch index
          • Business value
        • Add your own asset
        • Connect your stakes from EigenLayer, Karak, Babylon, Solayer, etc.
      • Claiming rewards
    • 🕵️Become a validator
    • Mobile & low power devices validators
    • ⚙️Customizations
      • Create own mutation
      • Create own plugin
      • Run your node over TOR
      • Plugins usage
    • Explorers and how to use them
      • Public Explorer
      • Your own custom explorer
      • Usage guide
        • Network Parameters
        • Searchbar
        • Network Info
          • Epoches data
          • Hostchain checkpoints
  • Web1337
    • Web1337 intro
    • 🟢Simple API requests
      • Block API
      • Epoch API
      • State API
      • Misc API
      • Consensus related API
      • Transactions API
    • 🟠Transactions and smart-contracts
      • Useful advices & FAQ
      • 🔐Default Ed25519 transactions
      • 🤝BLS multisig transactions
      • 🛡️TBLS thresholdsig transactions
      • ⚛️Post-quantum transactions
      • 📃KLY-WVM - deploy and interact with the smart-contract to WASM vm
        • Interaction with a smart-contract
      • 📃KLY-EVM - deploy and interact with the smart-contract to EVM
        • Interaction with a smart-contract
      • Transfer coins between EVM and native environment
    • 🔴Advance Web1337 usage
      • Parallel execution
      • Interaction with a system smart contracts
      • 🪄Abstraction
        • 🦸‍♂️Account abstraction 2.0
        • 💾Storage Abstraction
          • 🔃Manual deployment of the storage for your contract
          • ☄️Dump EVM & WASM contract storage
          • Pay for storage rent
        • ⛓️Chain abstraction
      • 🌩️Thundercloud
        • 🏷️Using KLY Aliases in transactions
        • 🦾Deploy KIP
      • Using boosts & subscriptions
    • 🌐Networking
      • 🙈Using proxy
      • ⚡Interact with node via websockets
  • Smart Contracts and vms
    • Intro
    • 👩‍💻KLY-EVM
      • Smart contracts examples
      • 🧙‍♂️Magic address
      • Beyond the VM
        • ❎Call WASM from EVM
        • ❎Call JS from EVM
    • 👨‍💻KLY-WVM
      • Smart contracts examples
      • 🔁Simple cross-contract call (WVM-WVM)
      • Beyond the VM
        • ❎Call EVM from WASM
        • ❎Call JS from WASM
    • Containers
    • 🤓Writing smart contracts
      • Get random value from contract
    • 🧠Advanced VMs usage
      • 🔐Cryptography
        • 🎲VRF
        • ⚛️Post-quantum cryptography
        • 👀zkSNARK
        • 🤫Secure Secret Sharing
        • 🤹Using MPC
        • 🙈Using FHE
      • ⛈️Thundercloud
        • 👀KLY Oracles
          • ⏳Get the real time
          • 🌏Call any API
  • 🗺️RWX contracts
    • ℹ️Intro to real-world-execution smart contracts
    • How to use RWX contracts in your project or business
      • Web2 usage
        • User-User - agreements between default people
        • User-Business - agreements between customer and business
      • Web3 usage
        • Use in standalone blockchain projects
        • Use in DApps
    • 🤝Create RWX contract and deploy with Web1337
    • 🕵️‍♂️Become verifier
  • 👀Interesting features you must know
    • 😦Return of lost funds
  • Misc
    • 🏷️KLY Aliases
      • Web2 domain to KLY Alias
      • Web3 domain to KLY Alias
      • Social media handle to KLY Alias
  • Bots
    • 🤖Intro
  • Nodes management and maintaining
    • Core version update
    • State pruning
    • Launch own PoD (point of distribution)
    • Recovery process
    • Fast sync
  • Shared security usage
    • For blockchain networks
    • For DApps
    • For bridges
    • For oracles
Powered by GitBook
On this page
  • FP - Finalization Proof
  • AFP - Aggregated Finalization Proof
  • LRP - Leader Rotation Proof
  • ALRP - Aggregated Leader Rotation Proof
  • EFP - Epoch Finalization Proof
  • AEFP - Aggregated Epoch Finalization Proof

Was this helpful?

Edit on GitHub
  1. Other resources & links
  2. Glossary & Taxonomy

Consensus

FP - Finalization Proof

Signature by some quorum member (validator) that told:

I agree to vote for block B with index I and hash H created by shard leader L. The previous block hash was P

On a more technical level - the validator that is part of the current quorum when receiving a block proposal from the shard leader generates a signature:

import {crypto} from 'web1337';

let prevBlockHash = "b5d6a3736a146fe921e40be95b8e41a0f953a20aedb740769440be4b53795ff7";

let blockID = "0:9GQ46rqY238rk2neSwgidap9ww5zbAN4dyqyC7j5ZnBK:1618";

let blockHash = "36514c7acfd77950b23baced61f70bd7126f5dac4bc7f2eb110f364123901c42";

// Epoch Full ID = epoch.hash+"#"+epoch.index
// Just concat hash + # + index
let epochFullID = "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef#0";

let dataThatShouldBeSigned = prevBlockHash+blockID+blockHash+epochFullID;


// Imagine that validator holds it locally
let quorumValidatorPrivateKey = "MC4CAQAwBQYDK2VwBCIEILdhTMVYFz2GP8+uKUA+1FnZTEdN8eHFzbb8400cpEU9";


let finalizationProof = await crypto.ed25519.signEd25519(dataThatShouldBeSigned,quorumValidatorPrivateKey);

After quorum member generate this signature - it can be handled(by someone - since it proof is public) and aggregated to get the AFP - aggregated finalization proof

AFP - Aggregated Finalization Proof

Aggregation of 2/3N of FPs gives us AFP. This is how it looks like:

{
    "prevBlockHash": "b5d6a3736a146fe921e40be95b8e41a0f953a20aedb740769440be4b53795ff7",
    "blockID": "0:9GQ46rqY238rk2neSwgidap9ww5zbAN4dyqyC7j5ZnBK:1618",
    "blockHash": "36514c7acfd77950b23baced61f70bd7126f5dac4bc7f2eb110f364123901c42",
    "proofs": {
        "9GQ46rqY238rk2neSwgidap9ww5zbAN4dyqyC7j5ZnBK": "0pOSDm2Zr615gDociLowbGD3IU3eXZKqXOpGchHx8pQEBFThgKzRE2Qt+jTw4ikKJruVCMlDHjwaFOJuufJSAA==",
        "6XvZpuCDjdvSuot3eLr24C1wqzcf2w4QqeDh9BnDKsNE": "msSzIiJ9R7x+U+aLUYWyJVF2ylB8qQmel0U7XHPSRXlRZtc+AJVGctXiDZ89K54xpWL+E9TqDmj9H2Cqvz+MAg=="
    }
}

In our explorer you can check the AFP on the block page - look at the link next to the status

Clicking on the link will show you the raw version of AFP:

Probably the most interesting field here is proofs - these are just the FP's from the validators that are part of the quorum of the epoch when the block was generated.

You can verify it yourself using this code:

import {crypto} from 'web1337';

let prevBlockHash = "b5d6a3736a146fe921e40be95b8e41a0f953a20aedb740769440be4b53795ff7";

let blockID = "0:9GQ46rqY238rk2neSwgidap9ww5zbAN4dyqyC7j5ZnBK:1618";

let blockHash = "36514c7acfd77950b23baced61f70bd7126f5dac4bc7f2eb110f364123901c42";

// Epoch Full ID = epoch.hash+"#"+epoch.index
// Just concat hash + # + index
let epochFullID = "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef#0";

let dataThatShouldBeSigned = prevBlockHash+blockID+blockHash+epochFullID;

// Let verify FP for quorum member 9GQ46rqY238rk2neSwgidap9ww5zbAN4dyqyC7j5ZnBK

let quorumMember = "9GQ46rqY238rk2neSwgidap9ww5zbAN4dyqyC7j5ZnBK";
let fpProof = "0pOSDm2Zr615gDociLowbGD3IU3eXZKqXOpGchHx8pQEBFThgKzRE2Qt+jTw4ikKJruVCMlDHjwaFOJuufJSAA==";


let isFinalizationProofOk = await crypto.ed25519.verifyEd25519(dataThatShouldBeSigned,fpProof, quorumMember);

// In case 2/3N+1 of quorum created valid FPs - then this AFP is valid

Sometimes, another case is also possible:

If you see something like this in the explorer, it means that the network has finished the epoch on this block. This block is also valid and was included in the state, but indirectly - via the process of voting for ending of epoch. Such AFP is impossible to verify and it used just as a stub for user interface of explorer

LRP - Leader Rotation Proof

Signature by some quorum member (validator) that told:

I agree to finish FPs generation for shard leader L on index I and hash H. The hash of first block by this leader is F

ALRP - Aggregated Leader Rotation Proof

Aggregation of 2/3N of LRPs gives us ALRP. This is how it looks like:

{
    "firstBlockHash": "a2d375da65094d65d25cc449abd10dfcea6c1b011cd0ce190379ca09b82b842b",
    "skipIndex": 131,
    "skipHash": "fb963df17e1b7f437636e4c5c94b32d43b86049393bafdf01299a304511c59eb",
    "proofs": {
        "9GQ46rqY238rk2neSwgidap9ww5zbAN4dyqyC7j5ZnBK": "W4Otr1LGk5KVYYBp+10hi3n2l+iVyNc+BgLYh3Yi4JEGiBG+MlozqSk4RjWu638ccAkeaebk6IhgmNKu8R9zAw=="
    }
}

EFP - Epoch Finalization Proof

Signature by some quorum member (validator) that told:

I agree to finish epoch X on shard Y. The last shard leader had index Q in leaders sequence. His last block has height W and hash H. His first block has hash F

AEFP - Aggregated Epoch Finalization Proof

Aggregation of 2/3N of EFPs gives us AEFP. This is how it looks like:

{
  
    "lastLeader": 2,
    "lastIndex": 31,
    "lastHash": "ab963df17e1b7f437636e4c5c94b32d43b86049393bafdf01299a304511c59eb",
    "hashOfFirstBlockByLastLeader": "b2d375da65094d65d25cc449abd10dfcea6c1b011cd0ce190379ca09b82b842b",
    "proofs": {
        "9GQ46rqY238rk2neSwgidap9ww5zbAN4dyqyC7j5ZnBK": "W4Otr1LGk5KVYYBp+10hi3n2l+iVyNc+BgLYh3Yi4JEGiBG+MlozqSk4RjWu638ccAkeaebk6IhgmNKu8R9zAw=="
    }
}
PreviousVirtual machinesNextRWX codeless smart contracts

Last updated 3 months ago

Was this helpful?

📚