What is LACChain?

LACChain is a Global Alliance integrated by different actors in the blockchain environment and led by the Innovation Laboratory of the Inter-American Development Bank Group (IDB LAB) for the development of the blockchain ecosystem in Latin America and the Caribbean.
Born in 2019, our goal is to accelerate the enablement and adoption of blockchain technology in the region to foster innovation, reduce economic, social, gender and all inequalities, to promote job quality and security, promote financial inclusion, consumer protection and market integrity.
The expected results are based on the empowerment of people, the improvement of digital security, the generation of trust on the economy and digital society, fostered in the efficient use of energy and thus supporting inclusive growth, wellbeing, human rights and fundamental values.

Why LACChain

The initial funders of the LACChain Alliance led by the IDB Lab identified a fragmentation and dispersion of the communities and blockchain networks that limit the efforts being made to adopt blockchain technology. Some of these included many silos in the ecosystem, scarcity of information, regulatory uncertaintly, very expensive costs related to the use of the technology, a very concerning carbon footprint, and thousands of blockchain networks that were not suitable for the scalability of government and enterprise use cases, the absence of international standards and protocols and the lack of collaboration and coordination among public, private, and academic entities. In this context, the rapid manifestation of the benefits that blockchain can contribute to our society and generate impact, especially in vulnerable populations, could be difficult to achieve.
In order to address this, the LACChain Alliance is focused on two big pillars: community and infrastructure. In terms of community, the LACChain Alliance supports national ecosystems and governments in LAC, has established regional and by-industry working groups, supports the organization of hackathons and challenges, and participates in standardization working groups, among many other tasks. In terms of infrastructure, the LACChain Alliance has built the largest permissioned public blockchain infrastructure in the world, with more than 100 entities from Latin America, the Caribbean, the United States, and Europe sharing a common network for their blockchain-based projects. This infrastructure is complemented with several tools for digital identity, digital credentials, tokenization, and digital money.

LACChain Networks

LACChain Networks are blockchain networks initially developed by the LACChain Alliance and now orchestrated by LACNet. These networks are classified as permissioned public blockchain networks, as defined in the standard ISO/TC 307. LACChain Networks follow the LACChain Framework.
As public blockchain networks, LACChain Networks are open to any entity in Latin America and the Caribbean. As permissioned networks, node operators must be authenticated and commit to comply with regulation in order to be permissioned. LACChain Networks have no transaction fees, facilitating the scalablity of blockchain-based initiatives.

Documentation Overview

Our Frameworks

LACChain Blockchain Framework

The LACChain Blockchain Framework is a set of recommendations to build neutral, secure, multipurpose, multiprotocol, regulatory compliant, and quantum-resistant blockchain networks. The document presents and discusses the concepts of operation, orchestration, and governance. It also addresses topology, routing and connections, block generation, publicness, permissioning, resource distribution, node signatures, quantum-resistance, scalability, monitoring and evaluation, decentralized storage, and private channels. It also tackles regulatory matters. All LACChain Networks follow this framework.

Read the document here

LACChain ID Framework

The LACChain ID Framework is a set of recommendations to build multipurpose, scalable, interoperable, secure, and privacy-preserving digital credentials and wallets. It covers decentralized identifiers, verifiable credentials and presentations, digital wallets, public key directories, trusted lists, certificate revocation lists, regulation, and trust frameworks. The LACChain Alliance has developed a complete open-source identity stack that follows this framework.

Networks Based on Hyperledger Besu

Hyperledger Besu

The most advanced LACChain Networks are based on Hyperledger Besu, an open-source, mainnet compatible, Java based, and Apache 2.0 licensed Ethereum client. For more information you can read the code and the documentation.

Topology

The nodes in the LACChain networks can be classified into two groups, according to their relevance for the functioning of the network. The two groups are core and satellite nodes. In each of these two groups there are also two different types of nodes, according to the specific tasks they are allowed to perform. Core nodes are classified into validator and boot nodes, and satellite nodes are classified into writer and observer nodes.

Core nodes

Core nodes play an essential role in the correct functioning of the network. The network can’t work without them. Core nodes are classified into validator and boot nodes.

Validator nodes

Validator nodes participate of the consensus protocol. They are responsible for the generation of on new blocks. Validator nodes are only connected to each other and to boot nodes for security and efficiency purposes.

Boot nodes

Boot nodes act as a liaison between validator and satellite nodes, which implies that (i) they listen to the writer nodes and pass along to the validator nodes the information about the transactions generated by writers, and (ii) they update the satellite nodes about the new blocks generated by the validator nodes. They are also responsible for setting up new nodes by providing them with a list of active nodes in the network, the latest version of the blockchain, and other relevant information such as whitelists and blacklists. Boot nodes are connected to all the types of nodes in the network.

Satellite nodes

Satellite nodes do not play an essential role in the correct functioning of the network. The network works without them. Satellite nodes are classified into writer and observer nodes.

Writer nodes

Writer nodes can broadcast transactions to the network. They communicate the transactions to the boot nodes, that pass them along to the validator nodes. They can also create private channels between themselves for private communication using the a Private Transaction Manager (e.g., Tessera). Writer nodes are connected to boot nodes and to other writer nodes.

Observer nodes

Observer nodes can only read the blockchain. Observer nodes are only connected to boot nodes.

Node discovery

For a P2P network work properly, there must be a good implementation of node discovery that allows a node to discover other nodes in the network. The discover protocol implemented in LACChain Blockchain Networks based on Hyperledger Besu to build the peer to peer network is based on Kademlia.

Kademlia is a well-defined distributed hash table recognized as a robust standard and protocol. LACChain Blockchain Network inherits from Ethereum (the underlying technology of Hyperledger Besu) the use of the discovery part of the Kademlia protocol.

To begin the discovery process, a node needs an identity. The identity of the node is achieved through an enodeID, which is then hashed with keccak into a 256-bit value. For more details, you can go to node identity. Once you have deployed your node and the node has been permissioned in the network, you node will start the discovery process.

The blockchain networks orchestrated by LACNet use UDP protocol to exchange information across the P2P network. The steps to achieve the discovery of nodes in the network are the following:

• LIST: When a new node aims to join a network, it needs to be provided with a list of nodes that are already part of that network so it can try to communicate with them. In LACChain Blockchain Networks, the addresses of the boot nodes are hard-coded and the list is located at /lacchain/config.toml.

• PING: The new node sends PING messages to all the boot nodes in the list and expects a PONG message in return. This pair of messages is used to determine whether a neighboring node is responsive.
• FIND_NEIGHBOURS: As soon as the new node gets PONG messages from responsive boot nodes, it sends a findnode message asking them for a list of 16 nodes of those they are connected to.
• CONNECT: At present, there is no limit for the number of nodes a new node can be connected to. Eventually, the number will be set to 25. In order to isolate validator nodes from writer and observer nodes for security and efficiency purposes, we are doing research on smart contracts for permissioning managed at a local level for each validator node, so they only whitelist boot nodes and other validator nodes for their communications.

To summarize, the discovery process to join a node to the lacchain network is as follows:

• Get a enode ID.
• Get the list of boot nodes.
• Bond to boot nodes:
  • Send Ping
  • On Pong do a findNeighbours
• Connect to active nodes
• Table of new node is persisted to minimize bootstrap requirements

Node communication

Once discovery is successful, nodes can have peer-to-peer communications over the LACChain Networks based on Hyperledger Besu. Communication consists in sending and receiving messages between nodes. For data transfer, Besu protocol relies on the RLPx Protocol. RLPx enables nodes to transfer encrypted and serialized data through encrypted multiplexed messaging.

This protocol leverages Elliptic Curve Integrated Encryption Scheme (ECIES) to establish secure communications between nodes using public key infrastructure and elliptic curve cryptography. After the handshake, both nodes send to each other which protocols and which versions of these protocols they support: The Ethereum protocol is “eth”, the Ethereum’s Whisper protocol is “shh”, and the Light Ethereum Node Subprotocol is “les”. The subsequent messages are dependent on the protocol chosen.

Through this protocol

• Writer nodes broadcast transactions to boot nodes.
• Boot nodes update writer and observer nodes on the new blocks generated by the validator nodes.
• Validator nodes agree on the generation of new blocks among themselves and broadcast to boot nodes the new blocks generated.

Consensus protocol

LACChain Networks based on Hyperledger Besu use IBFT2.0 consensus protocol for the validation of transactions and generation of new blocks. This is a Proof of Authority protocol that eliminate high carbon emissions involved in other consensus protocols such as proof of work. Additionally, all validator nodes in LACChain Mainnets are contractually committed with LACNet to follow certain rules that guarantee the resilience of the network without crypto incentives. For node operators to propose and discuss updates and changes in the LACChain Networks, LACNet coordinates discussion working groups. All of these guarantees that:

• Blocks need to be signed by 2/3+1 validator nodes to be valid.
• Finality is instantaneous or semi-instantaneous.
• History cannot be rewritten.
• Only nodes permissioned as validators can propose and vote new blocks.
• Validator nodes have a time slot to propose a new block. When time expires, the validator is replaced by another available validator.
• Validator nodes must accept any valid transaction and report any invalid transaction.
• Validator nodes must be resilient.

In LACChain Networks, validators do not compete to produce blocks, but rather take turns. As such, finality is instantaneous and new blocks are always appended at the end, never rewriting the history. If there were an attack by a majority of validator nodes trying to rewrite the history, any honest node in the network (including validators and not validators) could simply refuse to accept it as soon as the honest node finds that the hash of the block previous to the last proposed block does not match with the hash in the latest version of the chain the honest nodes have.

Additionally, we have developed a protocol to rotate validator nodes in a way that maximizes performance and decentralization.

Rotation of validator nodes

Overview

In the most popular permissionless networks, the consensus protocol is generally proof of work, originally proposed and adopted by the Bitcoin network. This consensus protocol introduces a reward for the block producers or validators, which is imperative in stimulating participation in these types of networks. As a trade-off, proof of work leads to the use of amounts of energy equivalent to the energy consumed by medium-size countries and reduces the decentralization of block generation down to only a few people who are in charge of mining pools, which are responsible for deciding which transactions go into the new blocks. However, in permissioned networks there is no need to stimulate validator nodes by rewarding them with a cryptocurrency. In general, in permissioned networks, validator nodes take turns to generate new blocks, and are operated by known entities that maintain these nodes because of their interest in the existence and well-functioning of the network to allow blockchain-based government and enterprise to scale.

Protocol for the rotation of validator nodes

The protocol for the rotation of validator nodes applied in LACChain Networks has 7 principles:

1. Validator nodes are divided into active and inactive.
2. The number of active validator nodes is fixed to 11, because 11 is the smallest number of nodes to allow for 4 validators down in a BFT/PoA scheme.
3. Any entity that complies with the network requirements to run a validator must be allowed to do it. These requirements must only have the goal of ensuring that an entity is capable of maintaining a reliable validator node.
4. Validator nodes are graded according to the Node Health Score, which is based on five metrics: blocks generated, block time, online time percent, decentralization, and block propagation time.
5. After well-defined  optimal  amounts  of  time,  active  and  passive  nodes    Rotation probabilities are calculated according to health scores (i.e., a node with a higher score has lower probability of being rotated out).
6. The Permissioning Committee supervises the process.
7. Active validators must enable the rotation with their votes (to add and remove the proposed validators).

GAS Distribution Mechanism

Overview

The throughput of blockchain networks is inherently limited. There are several reasons for this. First, blockchain networks are decentralized, which leads to time constraints for replicating transactions across the network and executing these transactions by the nodes. Second, nodes maintain a copy of the entire transactional history, which leads to space constraints because the size of the history needs to be controlled and limited in order to stay manageable. For this reason, networks limit the size and execution capacity that blocks and nodes can assume.
Throughput limitations lead to a “supply and demand” challenge. How can we manage situations in which the amount of individuals or entities that want to use a blockchain network exceed the network’s ability to support them? Permissionless networks have addressed this with dynamic transaction-fee models. The more network space and computational capacity a person or entity requires for their registries/transactions, the more they have to pay. Consequently, the more users are using the network, the more expensive it becomes for each of them to use it. It is a classic supply and demand approach: transaction fees go up until supply and demand curves meet and equilibrium is reached.
Because of that, there is a big problem with transaction-fee-based networks which is that they quickly become very expensive. The more successful they are in attracting users, the more unaffordable they become for these users. For example, Bitcoin transaction fee average oscillated between $2 and $63 over the year 2021, and Ethereum averaged transaction fees between $17 and $63 in the fourth quarter of 20212 , respectively. This is why transaction-fee-based blockchain networks can hardly be an option for government and enterprise use cases that generate large amounts of transactions. This becomes even more unfeasible when taking into account fee volatility, which makes forecasts for budget allocation very difficult.

Register and deploy a node

At present, there are three permissioned public LACChain Networks orchestrated by LACNet that use Hyperledger Besu as the underlying protocol. Each network has a different permissioning process to be accomplished before deploying the node.

Mainnet Omega

The Mainnet Omega is the network recommended for all the initiatives in production. The Mainet networks (just one at present) are . Writer nodes are required to pay a membership to contribute to the legal and technical teams of the non-profit orquestrator LACNet. These networks are aimed to ensure relisience and accountability via Service Level Agreements between any entity operating a node and LACNet. Find the details of the permissioning process here. To initiate the permissioning process, fill the permissioning form and a focal point from the membership team will reach out to you to help you through the process. After that, you can deploy your node using the following guideline:

https://github.com/LACNetNetworks/besu-networks/blob/master/DEPLOY_NODE.md

Testnets

Pro-Testnet: The Protestnet is the network is recommended for testing a solution before jumping into the Mainnet Omega. This network could be rewritten or interrupted following tests and simulation needs. In June 1^st, it will be mandatory for nodes and solutions running in the Pro-Testnet to be compatible with the GAS distribution protocol.

Testnet David19: The David19 network is a temporaty Testnet that has implemented the GAS distribution mechanism that runs in the Mainnet. This network will be turned down after June 1^st, and the only remaining Testnet will be the current Pro-Testnet.

The Testnet networks are free. There is no payment needed to deploy nodes in this network, nor any fee of any kind for sending transactions. In order to deploy a node, it is required to file a very short registration agreement form as well as reading, understanding, and agreeing with the terms of reference. Find the details for the permissioning process here. After that, you can deploy your node using the following guideline: https://github.com/LACNetNetworks/besu-networks/blob/master/DEPLOY_NODE.md

Memberships

You can choose between three different membership packages to deploy writer nodes that can send transactions to the Mainnet. You can get the one that best suits your throughput and technical support needs. To get your membership, fill the form in https://lacnet.com/lead-form-eng/ and a focal point from the membership team will reach out to you via email.

List of entities operating nodes in the network

Deploy your first smart contract

Visit here: https://github.com/LACNetNetworks/gas-management/blob/master/docs/tutorial/Deploy_SmartContract.md 

Recommendations for DAPP Architecture

visit: https://github.com/LACNetNetworks/besu-networks/blob/master/docs/DAPP_ARCHITECTURE.md 

Networks based on EOSIO

Despite not yet orchestrated by LACNet, the LACChain Alliance has developed and maintains a Testnet based on EOSIO technology. You can find all the details about it here https://eosio.lacchain.net/en/. 

Networks based on other Protocols

The LACChain Alliance and LACNet are agnostic to blockchain protocols and recognize the benefits of many emerging blockchain protocols. The research team is constantly following these progress and more protocols are expected to be incorporated into the stack of networks orchestrated by LACNet soon. 

LACChain ID Resources

Decentralized Identifiers (DIDs)

A DID is “a new type of identifier” that enables verifiable and decentralized digital identity. A DID identify any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides it identifies. A DID is a URI that associates a DID subject with a DID document allowing trustable interactions associated with that subject, as it contains information about the authentication methods to prove ownership of that DID, endpoints, and other attributes.

LAC DID Method

Each DID is associated with a document in JSON format that contains all the public keys, verification methods and services. The way to retrieve each DID Document depends on the method itself, however, following the efforts to achieve greater interoperability, LACChain has developed a service that aims to resolve any document (although at the moment it only supports more than 7 methods); The service is available at the following URL: https://resolver.lacchain.net, and it is also possible to deploy the same tool within any infrastructure through the Universal Resolver Repository.

Universal Resolver

LACChain has developed and maintains the LACChain DID method, which is a fully on-chain DID method based on the ERC-1056 standard. The “lac” DID method allows to maintain a fully on-chain management of DIDs, using smart contracts to store the DIDs and the information associated to them.

There is also implementation of LACChain DID Method in NodeJS. It provides the necessary methods and functions to interact with a DID and resolve a DID Document without the need to directly call the smart contracts.

LACChain ID Registry

DECIR DONDE ESTA EL DE LA MAINNET + LINK AL TUTORIAL

Verifable Credentials (VC)

A verifiable credential is a digital file that contains one or more key-value claims (e.g., birth date, name, qualifications, gender, citizenship, etc.) about an entity (the subject), issued by another entity (the issuer), and is verifiable by any entity (the verifier).

We are building and maintaining a public library of VCs that is aimed to incorporate VCs designed for and used in real use cases across Latin America and the Caribbean in areas such as education, health, energy, public administration services, and land registry, among others. This library is in the domain https://www.lacchain.net/credentials/library/{type}/{hash}/{version} and the VCs are also stored in the LACChain Github and in the LACChain IPFS nodes. Verifiable Presentations also need to be verifiable because the recipient must be able to assume that a legitimate credential holder is consenting to share that presentation with them. The mechanism is exactly the same as for Verifiable Credentials, i.e. a “proof” attribute in the VerifiablePresentation object.

Manuals

Schemas Repository

Each type of Verifiable Credential (VC) follows the basic scheme proposed by the W3C that defines the fields and data types. Similarly, it is possible to extend the proposed standard through schemes that define the new fields within a specific type of credential.

The schema of a VC is a JSON-LD file that describes the fields that the credential can contain, and the credential must point to that file through the “@context” field. Therefore, the JSON-LD file associated with the credential schema must exist in a public place where it can be accessed for later validation. Within the identity stack and with the purpose of maintaining a control of credential types, LACChain has created a LACChain Credential Repository where any entity can register its type of credential along with the associated schema for later publication within the registry that is located at https://id.lacchain.net

Verification Process

The LACChain ID Stack comes with the LACChain Verification Process that is presented in this section, which allows any verifier entity to accomplish diligent electronic verifications of digital credentials presented to them by holders.

The process of verification consists in six steps:

1. Verification of the digital wallet as an electronic service used by the subject
2. Verification of the validity of the credential
3. Verification of the status of the credential
4. Verification of the issuer
5. Verification of the presenter
6. Verification of the claims

At LACChain we have proposed that the entire verification process described above be carried out in an on-chain way, that is, using smart contracts based on EIP-712 and EIP-1812 for credential signatures and on-chain claims verification, respectively. One of the proofs of concept has been developed for the issuance of LACChain Academy academic credentials.

Exchange Protocol

Currently, there are not many solutions for the exchange of credentials, some proposals consist of exchange protocols over the internet (see DIDComm). At LACChain we have developed an ad-hoc solution for the exchange of Verifiable Credentials, exposing a REST API as an SMTP mail service.

The LACChain Mailbox is a secure and private system for the exchange of messages, VCs, and VPs. It is a controlled by a centralized service that allows entities identified using DIDs to send and receive messages that are stored encrypted in a secure database.

Authentication Protocols

In order to access a digital service, we use an authentication method based on OpenID Connect proposed by KayTrust called DIDConnect. This mechanism makes use of DIDs to perform the authentication. DID Connect introduces the usage of DID and Verifiable Credentials (VCs), which is a decentralized mechanism that allows the client to verify the identity of the user. The proposed authentication flows, together with the Diagrams, are described in the Authentication to Service Repository.

On-chain TLs, PKDs, roots of trust, and trust frameworks

The verification process of a VC consists of validating its proofs using cryptographic algorithms, ensuring that it has not been altered in any way. However, within this process nothing guarantees that another entity can issue a similar and fully valid credential. This last point is where it is necessary to define a Root-of-Trust mechanism that allows verifying which entities have the “authorization” to issue certain types of credentials, thus avoiding that they may be impersonated.

There are currently different centralized solutions to solve this problem, such as: Trusted List (TL) and Public Key Directories (PKD). LACChain has defined a form of Decentralized Root-of-Trust, making use of the same concepts but through Smart Contracts, with which TLs and PKDs can be deployed, and associated with the verification process of a VC.

Tutorials

Deploy a smart contract based DID Registry

https://github.com/LACNetNetworks/gas-management/blob/master/docs/tutorial/DID_en.md 

Deploy a smart contract based credential registry

https://github.com/LACNetNetworks/gas-management/blob/master/docs/tutorial/VC_en.md

Deploy a smart contract based public key directory

https://github.com/LACNetNetworks/gas-management/blob/master/docs/tutorial/PKD_en.md

Deploy a Mailbox

https://github.com/LACNetNetworks/gas-management/blob/master/docs/tutorial/Mailbox_en.md