While blockchain offers numerous innovations with its promises of decentralization and security, it also faces significant challenges such as scalability and efficiency. To address these challenges, Nuffle Labs has emerged with the Nuffle Fast Finality Layer (NFFL), a solution that provides finality within 3-4 seconds, quickly gaining attention in the blockchain space. In this article, we will delve into what NFFL is, its architecture, the technologies used, and the benefits it offers, with a focus on the technical details.

Ethereum Rollups and the Challenges

Ethereum rollups have emerged as a key solution to address the scalability issues of blockchain technology. Essentially, their function is to process transactions off-chain, reducing the load on Ethereum’s main chain. However, these rollups face challenges such as liquidity fragmentation and state fragmentation. Additionally, the varying transaction times (extended finality time) between rollups present another significant issue.

Liquidity fragmentation occurs when the same assets are held across different rollups, leading to a dispersal of liquidity. This situation creates price discrepancies and inefficient capital usage, resulting in a complex and costly experience for users. State fragmentation, on the other hand, slows down cross-chain transactions due to the incompatibility between rollups, further extending finality times. These challenges negatively impact the user experience by increasing transaction times and costs.

To improve the efficiency and user experience of rollups, it is crucial to overcome these obstacles. Addressing such scalability challenges in the blockchain space requires innovative solutions to ensure rollups can operate effectively.

NFFL and Its Core Technologies

Nuffle Fast Finality Layer (NFFL) is designed to provide a fast and secure settlement layer across blockchain networks. To achieve this goal, it leverages two core technologies: NEAR Data Availability (DA) and EigenLayer Actively Validated Services (AVS)

NEAR DA: NEAR Data Availability ensures the secure storage and verifiability of rollup data. This technology enables rollups to store state information in a reliable environment and share it securely with other networks. Nodes, known as relayers, continuously transfer data to NEAR DA, allowing rollup transactions to be completed quickly and reliably. This system contributes to maintaining data integrity and ensures efficient verification processes. I plan to share a more detailed article about NEAR DA soon.

EigenLayer AVS: EigenLayer Actively Validated Services allows ETH staked on Ethereum to be reused (restaking) to provide economic security and support data validation. This structure is used by AVS operators to securely verify and share rollup state information. These operators carry out the validation processes, ensuring that NFFL delivers secure and consistent transactions. EigenLayer AVS preserves data integrity within the Ethereum ecosystem, speeds up validation processes, and provides a reliable infrastructure for cross-chain transactions.

These two technologies play a critical role in ensuring the speed and security of NFFL, facilitating seamless interaction across blockchain networks.

NFFL Architecture

The architecture of the Nuffle Fast Finality Layer (NFFL) is built on two main off-chain actors: Operators and Aggregators. This structure is designed to ensure data security, guarantee transaction accuracy, and support cross-chain interaction. Additionally, it includes a set of on-chain contracts such as NFFL AVS contracts on Ethereum Mainnet, NFFL verifier contracts on rollup networks, and NEAR DA contracts on the NEAR network. These on-chain contracts coordinate data sharing and verification across networks.

Operators: Operators verify the state roots on rollups and relay these verifications to Aggregators. They compare the data stored on NEAR DA with their full nodes, detect errors, and complete the verification process. The BLS (Boneh-Lynn-Shacham) signature algorithm is employed during this process. BLS aggregates multiple signatures into one, speeding up the verification process while enhancing security. Operators also monitor updates to the EigenLayer AVS contracts, ensuring they track not only rollup state roots but also changes in AVS contracts.

Aggregators: Aggregators combine the verifications from operators to enable secure cross-chain data sharing. They gather BLS signatures from multiple NFFL operators and once a sufficient quorum is achieved, they aggregate the signatures and record them on-chain. This unified signature can be verified by programs and allows one rollup to securely accept the state roots of other rollups. Aggregators store the verified data on-chain and ensure it is shared seamlessly across different networks. These signatures, made accessible via APIs, ensure secure and consistent cross-chain transactions.

Transition to ECDSA: Despite the advantages of the BLS algorithm, a transition to ECDSA (Elliptic Curve Digital Signature Algorithm) is recommended. ECDSA provides support for larger operator sets and heterogeneous networks without losing the benefits of BLS. This transition allows NFFL to achieve broader scalability and compatibility, enhancing both security and flexibility. ECDSA signatures enable easier and faster management of operator set updates. This shift facilitates smoother data flow between blockchains and supports a wider range of operators.

Incentive and Fault Mechanisms

NFFL employs an effective mechanism to incentivize operators to approve correct transactions while addressing faults when incorrect transactions are validated. This system is crucial for maintaining the proper operation and security of the network.

Incentive Mechanisms: NFFL incentivizes operators to approve valid transactions, increasing their motivation to contribute to the network and improving overall efficiency. Specifically, operators who successfully complete Checkpoint Tasks can claim their rewards by providing a ZK Proof at the end of the challenge process.

Fault Mechanisms: NFFL also includes a fault detection system for operators that approve incorrect transactions. If an operator wrongly approves a Checkpoint Task, other operators can detect this fault through the Merkle Tree, and the faulty operator faces consequences. This system ensures that operators provide accurate and reliable data, preserving the integrity of the system.

Checkpoint Tasks and Challenge Process

NFFL uses mechanisms like Checkpoint Tasks and the Challenge Process to ensure data integrity.

Checkpoint Tasks are periodically carried out by operators, where messages are merged using a Sparse Merkle Tree (SMT). The resulting data is recorded on-chain. This mechanism continuously monitors and maintains the accuracy of the data on the network. Operators regularly audit the accuracy of all data in the network through Checkpoint Tasks, increasing the reliability of the system and preventing potential data manipulation. If a Checkpoint Task is found to be erroneous, it can be challenged by other operators and proven through ZK proof, leading to penalties for the responsible operator.

Challenge Process is not limited to Checkpoint Tasks; individual messages can also be examined in this process. By verifying the presence or absence of each message in the SMT, the system ensures flawless operation. This mechanism enhances the security and integrity of the network, enabling NFFL to facilitate smooth cross-chain interactions.

Operation of NFFL with the HelloProtocol Example

The architecture and operation of NFFL can be better understood through a simple protocol called HelloProtocol. HelloProtocol allows users to send and receive "hello" messages across different networks. This example is ideal for demonstrating how NFFL facilitates cross-chain interaction.

A user sends a "hello!" message on Network #2, and the message is recorded in the state of Network #2. The corresponding block is processed by NFFL, and an attestation for Network #2's state root is gathered. This attestation can be presented to any network, making Network #2’s state valid across other networks.

The HelloProtocol application receives this attestation gathered by NFFL and performs the verification process in the background. Once verification is complete, the user can securely receive the "hello!" message on Network #1. This process includes the proof of the message stored on Network #2 and the attestation provided by NFFL. The user experience (UX) is not negatively impacted, as all proofs are generated behind the scenes.

NFFL collects attestation for the updated state root of Network #2 from its operators. These operators compare the new state root with the data stored on NEAR DA and approve it using BLS signatures. The approved signatures are then recorded on-chain.

The Aggregator combines these attestations from the operators into a single aggregated signature and presents it to other networks. The HelloProtocol application receives this attestation and securely transfers the "hello!" message to Network #1. The NFFL Registry on Network #1 verifies the validity of the attestation and the message.

Throughout this entire process, the user does not have to deal with complex verification procedures; the messages are transmitted quickly and securely across networks, ensuring a seamless user experience.

What Awaits Us in the Future? - NFFL Future Developments

NFFL is designed with an architecture that will become even stronger and more flexible with future developments. Innovations like dynamic operator set changes and support for heterogeneous networks will make it easier for NFFL to adapt to different needs and risk profiles. Let’s take a closer look at these upcoming advancements:

Dynamic Operator Set: Operators will have the ability to choose which networks they support based on their own risk profiles. This capability will allow NFFL to reach a broader operator base and increase its flexibility. Operator set updates will be carefully monitored and managed to minimize synchronization issues between networks.

Transition to ECDSA: As mentioned earlier, a transition from the BLS algorithm to ECDSA is proposed. ECDSA offers broader operator support and network compatibility while making operator set changes easier and faster to manage. This shift will enhance NFFL's security and allow more operators to participate in the system.

Slashing and Incentive Mechanisms: Integrated with EigenLayer, slashing mechanisms will quickly detect and penalize faulty or malicious operators. Various incentive mechanisms are being developed to reward operators who perform accurate and reliable transactions. These advancements will improve the overall security and performance of the network.

Relayer Incentives: Special incentive mechanisms are being planned to cover the operational costs of Relayers transmitting data to NEAR DA and ensure the continuous flow of accurate data. Each network may independently incentivize its own Relayers, or a general incentive structure across NFFL may be established. This incentive structure is currently under development and stands out as an important step in supporting NFFL's success.

Conclusion

NFFL helps overcome current scalability and efficiency challenges by providing fast finality in the blockchain ecosystem. Fast finality offers a significant advantage, especially in cross-chain interactions, providing a more efficient, secure, and user-friendly experience. NFFL will play a crucial role in the future development of blockchain and redefine industry standards.