Why block lattice, and how is it different from blockchain?

Unlike traditional bitcoin-like blockchain, where all transactions are compiled in blocks in a single blockchain, block lattice (introduced by Nano) is a collection of multiple blockchains. That’s why we also call it blocklist as that’s how exactly the Lyra node database looks like - a big list (collection in nosql database terms) of blocks. Each user account adds transactions to their own blockchain. Such architecture enables extremely high scalability, instant authorization and settlements, super light clients (wallets), and other important features that are necessary for mainstream business adoption. Let’s review them one by one.

High Scalability (large number of tps - transactions per seconds) is achieved because each LYRA block contains just a single transaction which is added to a relatively short account blockchain, which allows the authorizer node to complete a processing (either authorization or settlement) of multiple transactions simultaneously, within a very short period of time. Only primary authorizer and backup authorizer nodes must carry the full block lattice, which means they are dedicated powerhouses of the network. Clients (wallets) don’t need a local node, and they carry only their relatively short account blockchains, or no blockchain at all (see the Light Clients section).

Instant Payment Authorizations and Settlements are achieved because each transaction consists of two blocks: send (authorization) and receive (settlement), while each block is authorized individually, returning immediate result to the client. In traditional blockchains, transactions are accumulated in blocks, and blocks are added to the same blockchain, which prolongs both authorization and settlement times to minutes and even hours.

While you may have heard that there are no chargebacks in crypto payments, in reality, when crypto payment transaction is successfully validated by one or more nodes (“accepted by the network”) and appears in the transaction pool, but not yet added to a block, or added to a block but did not receive multiple “confirmations”, this situation is somewhat equivalent to authorized unsettled payment card transaction. The scenario is very similar: while transaction is valid, it still can be rejected later because of blockchain reorganization due to fork, or it can be “stuck” forever in transaction pool and never make it to the blockchain (for example, miners can be reluctant to process it due to very low transaction fee). This is the situation with most blockchains including Bitcoin, Ethereum, Monero, etc. In block lattice, there are no chargebacks as long as the client received authorization response from the network which takes fractions of a second.

Super Light Clients are possible not just because each client has its own blockchain, but also because each block contains full information about account balance. Unlike traditional blockchains, where transaction is typically compiled from multiple inputs located in various blocks located all over the entire blockchain, only the most recent account block (not the entire blockchain, and not even a single account chain) is required for a Lyra client to process a new transaction. It means no blockchain database is required on the client side, and no scanning of a database located on local or remote nodes “in the cloud” is required for performing many fundamental client functions (such as payment transaction). Thus, Lyra clients can be easily deployed on IoT microdevices, mobile devices, and smartcards with limited CPU performance and storage space.

Block lattice architecture solved the locked balance problem. Since every transaction is written into its own block, and every transaction block is individually and instantly authorized by the network, there is no need to lock an account balance to prevent double spending. Once a transaction block is signed by the authorizer nodes it becomes the part of an immutable account blockchain which cannot be modified. The account balance becomes spendable right after authorization response (for any transaction) is received from the network.

Last updated