Technology sharing|Introduction to the reconstruction of Flow access node (Access node)

Original link : https://github.com/onflow/flow/blob/master/specs/access-node-architecture/index.md

Translation: Maris, technical ambassador of Flow Chinese community. Reprint please note the source.

overview

The Flow access node (Access node) has not undergone major changes since its launch, and its goal as a Flow universal gateway has been achieved. Even so, there are clear signs that the design of this part of Flow needs continuous improvement to better support scalability and increase the level of modular design of services and code. In addition, this is also part of Flow's vision, which is to set up permissionless and unsecured node types, so that builders can access Flow more conveniently and with a low threshold.

In this document, we propose to rebuild access nodes to enable permissionless operations. We leverage DPS (Streaming Data Serving Service) for state indexing and local script execution, greatly reducing the load on execution nodes. The proposed changes could also significantly improve the horizontal scalability of Flow operations.

This new architecture splits the existing access node module into the following components:

• Flow Blockchain Data Service encapsulates all direct interactions with the Flow network and participates in the state synchronization protocol, and provides an API to allow auxiliary components to query the state of the blockchain and subscribe to updates.

• The Flow Data Provisioning Service (DPS) uses execution status updates from the Flow blockchain data service to build a complete execution status index, enabling fast execution of local scripts at arbitrary block heights.

• Flow API service that provides a user-friendly way to query the state of the blockchain and send transactions to the network.

Flow API service and DPS are designed as optional auxiliary components, providing diverse and flexible options for their configuration and use when deploying infrastructure.

Overall objective

• Completely separate the existing Access Node code into un-stake Observer Service and staked Access Node.

• Split the Access API from the Access Node into an independent module and design it as an independent process/service, which will be able to handle any Blockchain Data Service. We call it Flow API Service.

• Encapsulates the Blockchain Data Service real-time synchronization system provided by consensus followers and execution state synchronization. These states can be accessed through the Protocol API and the State Streamer interface.

• The State Streamer interface is a generic component that allows any consumer, such as a DPS, to be accessed by the Blockchain Data Service.

target points not considered

• does not involve long-term history access (see other questions)

• Does not address operational issues with public nodes (rate limiting, access control, etc.)

Objectives

• The Blockchain Data Service processes raw protocol and execution state data received from the peer-to-peer network. These state data are sent to the caller through the Protocol API and the streaming interface.

• Use the State Streamer Registration API and State Streamer client to access the Blockchain Data Service state.

• The execution status of the DPS index is transmitted through the State Streamer in real time. These index states respond to script call requests through the DPS API.

architecture design

detailed design

Access nodes have provided the following so far:

• As a pledge node in the Flow network

• Participate in the pledge gossip network based on the status of the agreement

• Handle live access API requests from public callers

  • Perform basic request validation

  • Delegate script execution to upstream execution nodes

  • Delegate transactions to collection nodes for network processing

Script delegation to EN execution is an apparently relatively simple achievement that limits the scalability of access nodes and impacts transaction throughput. Furthermore, the scaling of Access API request processing is limited by the tight coupling of the code within the Access Node. The introduction of DPS is the first step towards a queryable locally held state that can be used to extend Access Nodes. Subsequently, execution state synchronization provides a decentralized way to share execution state across the network.

■ Modification of rights and responsibilities

The synchronization management of the blockchain chain mainly relies on a set of unified functions provided by the Blockchain Data Service. These functions are built by the Access Node based on the Observer Service and can be used as an independent module of the trusted chain state.

Blockchain Data Service

• Follow the protocol consensus and perform state synchronization

• Serving the State Streamer API

• Serving the Protocol API

The new Access Node version is designed based on the above original node functions:

access node

• Participate as a staking node in the Flow network

• Track agreement status and execution data at any time

• Accepts new transactions, validates them, and forwards them to collection nodes

• Connect to the public pledge libp2p network

  • Provides access to the Flow blockchain protocol and execution state through a public libp2p network that exposes state synchronization and execution data synchronization protocols

  • Relay a subset of messages from the staking network to the public network

The naming of Observer Service also reflects its non-participating role in the network.

Watch node service

• Participate in the Flow network as a consumer of public data, without staking or permission

• Track agreement status and execution data at any time

• Accept new transactions, verify them, and forward transactions to Access Nodes

FLOW API service

• Deploy as a standalone service

• Provide external Flow Access API (gRPC/REST)

• If the DPS is deployed, query the DPS API to perform a status query, otherwise return an error

• Query the downstream Blockchain Data Service on the node running the protocol status Protocol API

• Agent sends transaction request

  • Access Nodes proxy transactions to downstream Protocol APIs

  • Observer Services proxy transactions to downstream Access Nodes

DPS proposes two limited changes: pull consensus followers to Blockchain Data Service. Then deprecate GCP-based execution state synchronization and switch all chain synchronization logic to State Streamer.

Data Provisioning Services (DPS)

• Deployed as a set of independent services

• Connect to Access Node or Observer Service through State Streamer API

• Subscribe to the protocol and perform state updates based on the State Streamer API

Stateful Streams and Stream Registry API

• Provides an API for subscribing to agreements and performing status updates

• Provide 1:1 data service (probably gRPC over web sockets)

• Scope of License (not intended to be released to the public)

• Provides an abstraction layer so clients do not need to interact directly with the Flow network

• The API performs data docking through the Execution Data Module and the data Protocol State Module

Refactor detailed architecture diagram

initial point

Refactoring Step 1

Non-structural considerations:

• Formalize State Client and State API specifications

• According to the configuration statement, establish the correct libp2p network Access Node in the bootloader and initialize the Observer Service

Blockchain core service construction

Build Flow API service

Subsidiary question

• Historical data access issues:

  • While this new schema does not support direct access to historical state in this initial revision schema, we are working with community partners to make this possible.