AD3.8.4E-Guidelines and recommendations For writer node operators

Guidelines For Writer Nodes

Here we analyze the GAS distribution mechanism from the perspective of writer node operators. First, we review the only two modifications they need to introduce into solutions developed for Ethereum and Hyperledger Besu Networks in order to be adapted for LACNet GAS distribution mechanism and therefore to work in LACNet Networks. Second, we provide recommendations for writer node operators to protect their nodes from potential attacks.

Modifications to Solutions Developed for Ethereum Networks

As mentioned before, this GAS distribution mechanism has been designed to be as transparent as possible for end-users. Thus, the writer node back-end wraps the original transaction into a meta-transaction and signs it as required by the proxy smart contracts.

This GAS distribution mechanism brings only two small changes for end-users. The first is a difference in how to retrieve the original sender of a transaction and the second is indicating the writer node and the expiration time selected to broadcast the transaction.

Retrieving the Original Sender

The original transactions are not sent directly to the Recipient Smart Contract but by the RelyHub Contract (once it is checked that they meet the requirements). The transactions going to the RelyHub are, as explained before, meta-transactions wrapping the original transactions which are generated by the writer nodes.This makes it such that the sender of the transactions (the meta-transactions) reaching the Recipient Smart Contract is the RelayHub contract.

Because of this, it is necessary to have a mechanism to obtain the address of the original sender of the final meta-transaction (i.e., the client or user who sent the transaction to the writer node). To achieve this, we take advantage of the atomicity of the transaction execution in the EVM. That is, every time a transaction is sent to the RelayHub, the address of the original sender is stored, which is then retrieved by making a call to the RelayHub from the recipient contract.

This function to obtain the original sender is located in an abstract contract, which has to be inherited by all the contracts that will be deployed in the network.

Specifying Writer Node Address and Expiration Time

To avoid various attacks, end-users, applications and services on top that send transactions must add two new parameters to their transaction to indicate the address of the node they want to broadcast their transaction to as well as the expiration time for the transaction to be executed. These two parameters are checked by validator nodes against the Transaction Permissioning Smart Contract. Parameters are as follows:

nodeAddress(type:address): This parameter is the address associated to the private key that signs the transactions in the RelaySigner. Otherwise, by default, it is the address of the writer node through which the transactions will be sent.
expiration(type:uint256): This parameter is the timestamp (Unix timestamp) that determines the expiration time for transaction to be executed. After this time, the transaction cannot be executed (added in a block).

Security Recommendations for Writer Node Operators

Writer node operators are contractually committed to LACNet to not send transactions with a GAS limit higher than what they have left per block, nor violating any other rule in the network-under penalty of being banned. Therefore, the entity operating the writer node must ensure that neither its use of the node nor the use by authorized third parties (e.g., applications and end users) violates these clauses.

It is not the responsibility of LACNet to mitigate attacks from writer nodes by corrupt end-users or node administrators, because the operation of these nodes is the responsibility of the writer node operators. Further, even if security layers were developed, the operators of these nodes could always modify them, generating vulnerabilities that would fall under their responsibility. This is due to the decentralized architecture of the network, which allows each node to be self-managed.

However, LACNet is not intended to let these writer node operators down with regard to potential attacks by end-users, services and applications on top, or others. On the contrary, LACNet has identified a set of threats posed to writer node operators and has provided tools, protocols, and suggestions for the writer node operators to mitigate any attack either to them or to the network through them.

It is important to note that even in the event that the writer node operator does not want or cannot protect the writer node from the attack, the attack will not affect the network and other node operators because the malicious node will be immediately banned as soon as any attempt of misbehavior in the network is identified (such as exceeding GAS limit).

Restricting and Protecting Access to the Writer Node

With prior knowledge that a writer node is exposed, attacks could be carried out by malicious users from both outside and inside the network. It is essential that writer nodes’ RPC and WebSocket ports are never open publicly without some layer of security. In the case of boots and validators, both types of nodes are committed via the Adscription Contract to not have RPC nor WebSocket open, and to not have APIs enabled for sending transactions.

Checking and Filtering Transactions

Each network writer node has the ability to deploy 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 node under rules customizable by the writer node operator.

This allows for each writer node operator to define its own rules for broadcasting transactions to the network. For writer nodes exposed to external users, services, and applications, this is extremely important, because writer node operators will be accountable for the transactions their node broadcasts, no matter who the original sender is.

Examples of rules include verifying the trail, the GAS limit, the destination of the transaction or the GAS price. They can also be more granular rules, such as verifying the data being sent in the transaction.

Resending and Overwriting Transactions

Transactions sent by an innocent node to the network are replicated to all bootnodes. The bootnodes then replicate the transaction to the other writers and validators, which then execute the transactions. A malicious node could see a transaction in its pool and attempt to extract and forward it through its malicious node. It would do so with the intention that the second transaction is executed by the validators and the original transaction is executed with errors with its GAS consumed anyway. Even if the original transaction is executed at the attacker’s expense, the end-user might be cheated because the end-user’s attempt would be unsuccessful.

This potential attack is mitigated by the requirement that transactions must specify the writer node that is selected to broadcast them (otherwise they are rejected by the Transaction Permissioning Contract). Therefore, transactions will only be accepted if they have the signature of the node address that was indicated by the end user. Additionally, end-users must indicate an expiration time..

An alternative version of this attack could be to attempt to overwrite a transaction by increasing the GAS price of the duplicated transaction so validators are more likely to accept it first. This is impossible because the network has a GAS price of zero, so any transaction with a GAS price higher than zero is also rejected by the Transaction Permissioning Smart Contract.

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