Kaleido Open Menu
Close Menu
Log In Try It Free

Polygon Edge

Kaleido supports Polygon Edge, a modular and extensible framework for building private or public Ethereum-compatible blockchain networks.

Technical Overview

There are 6 main modules within the architecture of Polygon Edge.

  • JSON-RPC: This is the API layer that conforms to Ethereum client standards. Tools such as Remix, Metamask, Web3.js, Ethers.js, Hardhat, etc. all work with Polygon Edge.

  • TX Pool: This is the module that holds pending transactions and acts as the transaction pool. Transaction can be added from multiple sources and it is closely linked with other modules within the system through an event-driven architecture.

  • Blockchain: This is the state database that holds information about world state, smart contract code, accounts, and more. There are two key packages. The first is the RLP serializer that puts data in an Ethereum-readable format. The second is a data aggregator that puts data in Merkle Trees for fast lookups and verifications of immutability.

  • Consensus: Supported consensus algorithms include IBFT PoA (proof of authority) and IBFT PoS (proof of stake). Kaleido currenlty supports IBFT PoA with plans to add IBFT PoS in the future. More details may be found in the Consensus section.

  • Libp2p: Modern peer to peer networking stack that facilitates consensus messages, block syncing, SAM Pool gossiping, and Tx pool gossiping.

  • GRPC: Protocol used for issuing privileged operator commands. These commands can only be run locally on validator nodes to run online backups, fetch validator information, and query & clean the Tx pool

Trust Model

The Polygon protocol is designed to operate in a trustless environment, where no assumptions are made about the safety of the incoming transactions and block relay messages. Each node independently validates every transaction by executing the smart contract. All nodes are expected to have exactly the same copy of the "ledger", or the long list of transactions packed into chains of blocks. Rogue behavior can be easily detected by mismatched hashes from the different states that do not fit in the merkle tree.

The transaction model also makes no assumptions about identities other than valid signatures. In fact, the smart contract knows nothing about the real identities behind a transaction's signing key. To make this work in an enterprise context, where strong KYC (Know Your Customer) requirement is the norm, application developers must resort to custom components and off-chain mechanisms to manage identities and permissions.

For this reason Kaleido has built a pluggable Organizational Identity Registry that allows real world identities to be projected onto the onchain world with verifiable cryptographic proofs. This registry design has been adopted into the latest version, v5, of the EEA Technical Specification.

Privacy

The basic design principle in private transactions is to encrypt the payload and send to the counterparties directly, while broadcasting a commitment (a hash) of the transaction to the entire network as a proof of event for non-repudiation purposes. This way only the counterparties know the transaction details while at the same time the safety is guaranteed by the decentralization of the whole network.

Another key aspect of privacy is about hiding the identities of the counterparties. Because in Polygon all transactions must be broadcast to all participants in the network, competitors can gain a fair amount of insights by tracing the signing keys behind transactions and analyze trading patterns. A clever solution is to use one-time signing keys. Signing wallets such as Hierarchical Deterministic Wallet (HDWallet), using cryptographic key derivation algorithms, can produce practically unlimited number of signing keys seemingly not related to each other from a single seed secret. Using wallets such as HDWallet makes it possible to use one-time signing keys without having to separately keep track of each key in a huge database.

Finally, some use cases require a globally coherent state to be used to validate transactions. For instance, in a token economy it is essential to be assured that any token is not double-spent. While many token types are robustly supported in Ethereum, it also requires all account balances to be transparent to all the participants in the network. In order to maintain a global state without having to disclose counterparty's account balances, advanced techniques such as zero knowledge proofs can be used. Ethereum has been a fertile ground for designing and proving zero knowledge proof algorithms, such as Aztec, PLONK, Halo and FRI. Some of these technologies have been integrated into the Polygon ecosystem with Polygon Zero, Polygon Nightfall and others.

Consensus

IBFT PoA is the default consensus mechanism for Polygon Edge. In IBFT, validators are the ones responsible for creating the blocks that get added to the blockchain.

All of the validators make up a dynamic validator-set, where validators can be added to or removed from the set through a voting mechanism. This means that validators can be voted in/out from the validators-set if a majority (51%) of the validator nodes vote to add/drop a certain validator to/from the set. In this way, malicious validators can be recognized and removed from the network, while new trusted validators can be added to the network.

All of the validators take turns in proposing the next block (round-robin), and for the block to be validated/inserted in the blockchain, a supermajority (more than 2/3) of the validators must approve the said block.

Besides validators, there are non-validators who do not participate in the block creation but do participate in the block validation process.

Programming Model

Polygon transactions only need to be sent to a single node, typically one either operated by the organization itself or a trusted operator, which will in turn broadcast it to the entire network.

Transaction ordering in Ethereum is provided through per-account nonces, a sequentially incremental number, which must be consecutive. If there are gaps in the transaction nonces, all transactions with nonces after the gap are held in the TX pool until the gap is filled in with transactions using the missing nonces.

The application typically is responsible for figuring out the right nonce to use and sign the transactions accordingly. This can be complex, especially when transactions are submitted from multiple application instances. Kaleido has developed a robust solution to alleviate application developers of these low-level, complex programming concerns, with the REST API Gateway.

Smart Contracts

Smart contracts in Polygon are EVM (Ethereum Virtual Machine) bytecode compiled from high level languages such as Solidity. Many essential developer tools are available, such as:

For life cycle of smart contracts, Ethereum follows the approach that contract code is immutable. Once deployed it is saved on the chain as an immutable state. If updates are needed, new deployment will result in a completely different instance of the contract code living on the chain.

Techniques such as proxy contracts are available to make smart contract upgradeable.

Asset Tokenization

Tokens is a powerful programming model to make transactions interoperable based on universally recognized interfaces. The Ethereum community has pioneered many types of tokens, fungible or non-fungile, divisible or whole, mintable, burnable, etc. All have gone through validation with active deployment on the public mainnet.