Solution

Overview

In order to manage the use of GAS in Ethereum-based permissioned public blockchain networks that have erased transaction fees, LACNet has developed the first GAS distribution protocol of its kind. LACNet’s GAS distribution protocol presented in this document is aligned with the LACChain Framework for Permissioned Public Networks.

Often, GAS distribution protocols for blockchain networks consist of a faucet from which account owners can request GAS. This has notable limitations. One limitation is that it might be difficult or impossible to prevent permissioned entities from transferring GAS to non- permissioned entities which, in a permissioned network, might enable non-permissioned users to broadcast transactions. Another limitation is that it might be difficult or impossible to prevent a permissioned or non-permissioned user to accumulate GAS and use it to provoke a DoS attack and collapse the network by using all that GAS in a short period of time.

LACNet’s GAS distribution protocol for Ethereum-based Networks consists of a set of smart contracts that, among other things:

  • Assign GAS per block to the accounts associated with permissioned writer nodes in a dynamic way based on how stressed the network is at each time point (the more stressed it is, the less GAS is distributed). GAS is not distributed or made available directly to end-user
  • Serve as a proxy to evaluate every transaction sent to the network and check that (i) each transaction has been signed by a permissioned writer node and (ii) the writer node has enough GAS left for registering that transaction in the current.

This protocol gives the power and responsibility to writer nodes rather than end users, as writer nodes will have access to the GAS that allows to broadcast transactions. Therefore, writer nodes decide which end-users they allow to use their node and also their GAS to send transactions to the blockchain. Writer nodes are required to intercept each transaction they receive from end-users or client applications and wrap them into meta-transactions they then broadcast to the network. These meta-transactions contain the original transaction as well as the signature of the permissioned writer node that is broadcasting the transaction to the network.

Instead of sending the transactions to the recipient contract indicated by the original end-user sender, the writer node is required to send the transactions to a set of proxy smart contracts. In general terms, these smart contracts verify that the writer node has enough GAS and the signature is valid.

Architecture

A high-level architecture diagram for the implementation using Hyperledger Besu as the underlying protocol is presented in Figure 1. The solution has two main components:

  1. The smart contracts that contain the logic described in the previous section.
  2. The writer node back-end components necessary to generate, sign, and send the meta-transactions to the proxy smart
Figure 1. High-level architecture diagram.

Smart Contracts

A high-level architecture diagram for the implementation using Hyperledger Besu as the underlying protocol is presented in Figure 1. The solution has two main components:

  1. The smart contracts that contain the logic described in the previous section.
  2. The writer node back-end components necessary to generate, sign, and send the meta-transactions to the proxy smart.

The proposed solution involves six smart contracts: the Transaction Permissioning Smart Contract, the Node Permission Smart Contract, the RelayHub Smart Contract, the GAS Management Smart Contract, the Recipient Smart Contract, and the Local Account Permissioning Smart Contract. These smart contracts play two roles: 1) realize the GAS distribution protocol perse by carrying out GAS accounting and distribution, and 2) verify the transaction permissioning (both at the network and writer node levels)

Transaction Permissioning Smart Contract: The role of this contract is to only allow transactions that meet the network requirements:

  • Transactions must be directed to the RelayHub smart contract.
  •  Transaction GAS price must be 0.
  • The GAS limit of the transaction must be sufficient enough to execute the RelayHub smart contract.
  • The writer node that broadcasts the meta-transaction must be the one indicated by the end-user or application in the original transaction and the expiration time for the transaction set by the end-user must be respected.
 

Transactions that do not satisfy these rules will be rejected by the network.

Node Permissioning Smart Contract: This contract contains the list of permissioned nodes and defines the rules for TCP connections between nodes according to the topology and the routing rules explained in the LACChain Blockchain Framework for Permissioned Public Networks. Nodes that are not registered in this contract cannot connect to the network. Before two nodes establish a connection, they must verify against this contract whether the connection is allowed.

Relay Hub Smart Contract: This contract is based on the EIP 1077.5 The contract receives a meta-transaction (the transaction generated and signed by the writer node containing the original transaction sent by the sender) whose data field is decoded by RLP to obtain the parameters of the original transaction, which are the address of the original sender, GAS limit, nonce, original data sent, and destination address. The RelayHub Smart Contract validates the signer’s signature against the original message to guarantee that the message came from the signer. Then, it verifies that the node has not reached the GAS limit for that block. If everything is correct, the transaction is forwarded to the recipient contract indicated by the original sender (if there is one) or creates a new smart contract (if that was the intention).

GAS Management Smart Contract: Keeps track of how much GAS each permissioned node (the address or addresses associated to it) has per block, and registers how much GAS is being consumed in the last N blocks. It also sets the GAS limit that each node can consume depending on the network’s degree of stress in the last N blocks.

Recipient Smart Contract: This contract is the final destination of the transaction sent by a user or client application (unless the transaction was not intended to call an existing smart contract, for instance, because it was intended to deploy a new contract). This contract executes the function chosen with the parameters sent in the original transaction.

Local Account Permissioning Contract: Writer nodes can deploy, maintain, and customize a Local Account Permissioning Contract, which is a permissioning layer that writer node operators can use to filter (by whitelisting) the reliable addresses (senders) they allow to send transactions to the network through their writer nodes under rules customized by the writer node operator such that transactions that do not meet the requirements are broadcasted to the network. This allows for each writer node operator to define its own rules for transactions to be broadcasted to the network. For writer nodes exposed to external users, services, and applications, this is extremely important because writer node operators are accountable for transactions that their node broadcasts, despite who the original sender is.

 

When a new node is added to the network, the Permissioning Committee registers it into the Node Permissioning Smart Contract. Next, the organization senders’ addresses, whose node was previously added to the Node Permissioning Smart Contract, are added to the Transaction Permissioning Smart Contract. Automatically, the Transaction Permissioning Smart Contract invokes the GAS Management Contract which sets a GAS limit for the new node addresses and recalculates the GAS limit for the existing nodes.

Figure 2. Representation of the flow for adding a new node and sender address.

Each time a transaction is sent to the network, nodes check it against the Transaction Permissioning Smart Contract. First, writers check the transaction coming from the off- chain service or application, then boots check the transaction coming from the writer, and finally validators check the transaction coming from the boots. If the transaction does not satisfy the requirements (described above), the transaction will be rejected (i.e., not executed and erased from the transaction pool).

The validator nodes of the network, which are responsible for generating blocks, have the Transaction Permissioning configuration set, which makes them check every transaction they receive against the Transaction Permissioning Contract before they are executed in the network. It is worth mentioning that if a validator node becomes malicious by modifying the configuration of its node to accept invalid transactions into the network, this validator node will be banned by the other validators. For an invalid transaction to be introduced into a block, ⅔ +1 validator nodes need to be corrupted. If validator node operators tried such an attack, they would incur a legal penalty because validator nodes are committed contractually to not attack the network.

 
Figure 3. High level flow of the verification of transactions against the Transaction Permissioning Smart Contract by Validator Nodes

When the transaction meets the validity conditions, validator nodes execute the transaction against the RelayHub contract, where the nonce is verified to be greater than the previous one in order to guarantee that the transaction is unique and not duplicated. Before the transaction is forwarded to the Recipient Smart Contract (or creates a new smart contract itself ), it is verified that the node has not consumed all the GAS assigned to it for that block GAS Management Contract. If the transaction GAS limit is lower than the amount of GAS remaining for the writer node in the current block, the transaction is executed and the amount of GAS used is discounted in the GAS Management Contract. If the transaction execution cannot be completed, the amount of GAS consumed is discounted and a “not enough GAS” error event is emitted.

Figure 4. Representation of the flow for sending a transaction that consumes 200,000 GAS.

The RelayHub emits an event when a bad or doubtful transaction is sent, including:

  • The nonce sent is repeated or lower than the one registered in the contract for that user’s
  • The GAS limit sent in the transaction exceeds the block logical GAS limit set in the contract (it is not the same as the genesis GAS limit).
  • The transaction is sent to a contract that has an empty
  • The transaction tries to deploy an empty code
  • The user transaction has an invalid
  • The GAS limit of the transaction exceeds the amount of GAS left available for the writer node that is broadcasting the transaction.
Figure 5. Representation of the flow for sending an invalid transaction.

When an organization that owns a writer node exceeds the GAS limit assigned to them in a block, it will be marked as an “exceeded GAS limit” error and the organization responsible for the writer node is automatically removed from the Transaction Permissioning Contract, which prevents it from sending transactions. When a node is banned, the Permissioning Committee reaches out to the node operator to clarify the situation and add the node back into the Transaction Permissioning Contract.

Figure 6. Representation of the flow for exceeding node GAS limit.

When a private transaction is sent by the end-user or application to the writer node, it goes through the RelaySigner, which calls the GAS Management Smart Contract to discount a fixed amount of 25000. Then, it redirects the transaction to the Besu process, and this is communicated with the Private Transaction Manager (PTM) service, which shares the transaction with the PTM nodes indicated trough the private channel.

Figure 7. Representation of the flow for sending a private transaction.

Writer Node

The LACNet writer nodes consist of a Besu node configured as a writer (according to the LACChain topology) and is provided with a nginx and a RelaySigner. We have designed the GAS management solution to be as transparent as possible to end-users, meaning that services and applications on top can send transactions almost as if the proxy smart contracts did not exist. It is the writer node that turns the transaction in a meta-transaction that meets the GAS and node-signature requirements. Writer nodes can also deploy a Local Account Permissioning Contract as a filter to avoid unknown accounts from using their node.

Nginx: Acts as a reverse proxy and SSL termination (terminates HTTPS traffic from clients). It accepts all transactions to the node and forwards them to the Direct queries to the node do not go through the RelaySigner; nginx redirects them to the Besu RPC port.

RelaySigner: Evaluates the type of message from an application (service or end-user) that arrives to the node. If it is a raw transaction (RLP unsigned from final user or application), then the RelaySigner decomposes it, builds a meta transaction, signs it, and sends it to the network. If it is another type of message, such as contract calls, the RelaySigner gets the recipient, number of connected nodes, block information or transaction, and forwards the message directly to the Besu component.

Besu: A client of the LACNet network, with which the p2p connection is It broadcasts transactions to the other nodes of the network. This component receives meta-transactions from the RelaySigner to broadcast to network.

 

Requirements for Transactions to Be Valid

The node back-end components allow writer nodes to send only valid transactions to the network, and they will be banned if they decide to manipulate these components such that invalid transactions are sent. Transactions that do not meet the requirements detailed below are rejected by all the non-corrupted nodes after they check them against the Transaction Permissioning Contract. The Transaction Permissioning Contract is a security layer of rules to determine whether a transaction should be executed and included into a block . As explained above, every node that listens to a transaction check that it is a valid one before replicating it. Therefore, it is first the writer’s check followed by the boot’s check, and afterwards by the validator’s check.

  • The destination of the transaction must be the RelayHub (relay contract), through which all transactions must go through.
  • The GAS limit set for the transaction must cover the RelayHub execution (fixed and variable parts). The variable part of the GAS limit depends on the amount of bytes sent in the transaction, which guarantees the execution of the RelayHub contract and avoids exceptions for lack of GAS (an out of GAS exception).
  • The GAS price sent in the transaction must be 0, because in networks orchestrated by LACNet the GAS price is always 0.
  • In order to guarantee that the transactions sent by end-users or services and applications on top are not altered by writer nodes or malicious parties, the original sender is required to add two additional parameters to the function parameters of the destination contract: the “nodeAddress” and the “expiration”. Doing this guarantees that a transaction sent by an end-user cannot be re-sent by any node other than the one selected by the end-user and the transaction is not executed after the expiration time indicated by the end
  • The transaction sender must be an address registered by the organization running a writer node in the Transaction Permissioning Contract, which prevents anyone from sending transactions to the Additionally, transactions must be signed with the private key of the organization node’s registered address, which must also match the nodeAdress selected by the end user to broadcast its transaction. Only permissioned writers can send transactions to the network.
 

GAS Distribution Algorithm

The frequency with which the new GAS limit is set for each participating writer node of the network is every N blocks. This parameter is configurable by the Permissioning Committee. In order to determine the GAS limit for each node per block, the Permissioning Committee establishes the maximum amount of GAS that the network can process per block without suffering delays in the block generation, GT.

The type of membership the node has purchased determines the amount of GAS per block the node has access to. LACNet has [three memberships](LINK):

Basic membership: The node GAS limit is set to 0.5M per block.

Standard membership: The node GAS limit is set to 1.5M per block.

Premium membership: There is not a pre-defined GAS The GAS available per block minus the GAS reserved for basic and standard nodes is distributed equally among all the premium nodes.

Table 1 gives the ideal amount of GAS consumed on average by different typical transactions in the networks orchestrated by LACNet.

 
Table 1. Estimated average amount of GAS consumed by frequent transactions.

The idea of “reserving GAS” can lead to scenarios where some nodes might not be using all their GAS per block whereas others might need more. For this reason, this GAS distribution protocol is very flexible and attempts to maximize the amount of GAS per block made available to each premium writer node. This is achieved by updating the GAS limit every Y blocks for premium nodes according to how much the network is being used by all the permissioned nodes.

The amount of GAS available for each premium writer node per block changes dynamically depending on how much GAS all the writer nodes have used in the last N blocks (this parameter is adjustable). The higher the amount of GAS used by the writer nodes, the lower the GAS limit will be. If all the nodes (basic, standard, and premium) have reached the GAS limit available to them per block, then each premium node will have a GAS limit per block equal to the total amount of GAS minus the GAS reserved for basic and standard, divided equally by the number of premium nodes. If writer nodes have not used all the GAS assign to them, premium nodes are allowed to spend up to 5 times the previous amount up to 50% of the total GAS available for all nodes-.

The formula to calculate the GAS limit per block is as follows:

  • NB : Number of writer nodes with Basic membership
  • NS : Number of writer nodes with Standard membership
  • NP : Number of writer nodes with Premium membership
  • GT : Amount of GAS per block that the network can process without operating under
  • GB : GAS limit per block for writer nodes with Basic membership
  • GS : GAS limit per block for writer nodes with Standard membership
  • GP : GAS limit per block for writer nodes with Premium membership
  • ϑ : Fraction of consumed on average in the last 10 minutes by all the writer

This formula leads to the following scenarios:

Table 2. Relationship between usage of the network and GAS limit for premium writer nodes.

Let’s explore the formula with an example. Let us suppose that the amount of GAS per block that the network can process without operating under stress (GT) is 150M. Let’s also set the GAS limit for basic nodes in 0.5M and the GAS limit for standard nodes in 1.5M. In a network with 20 basic, 20 standard, and 20 premium nodes, basic nodes would have access to a maximum of (0.5M GAS limit x 20 nodes) 10M of GAS, and standard nodes would have access to a maximum of (1.5M GAS limit x 20 nodes) 30M of GAS. The 20 premium nodes would then have access to a maximum of (150M GAS total – 10M GAS for basic nodes – 30M GAS for standard nodes) 110M of GAS to be equally used among them, which is equal to a GAS limit per premium node of 5.5M GAS per block. But this is the case only if these 60 nodes are using all the GAS they have available (thus the parameter ϑ is equal to 1). If, conversely, the under 20% of the network network is used (the 150M of GAS per block), then basic and standard nodes would keep their 0.5M and 1.5M GAS limit per block, respectively, but premium nodes have up to 5 times higher GAS limit, which in this example, would mean (5.5M GAS limit x 5) 22.5M GAS limit per block. Appendix A presents results of stress tests performed in the LACNet Networks using the GAS distribution mechanism. Appendix B analyzes the monthly cost in Ether and USD of this amount of GAS in the Ethereum Mainnet.

Check our terms and conditions, privacy policies, and cookies policy.

Twitter Linkedin Youtube

Copyright 2024 © All rights Reserved. Designed by LACNet