🥅Functional Requirements

Functional Requirements of the Aurinko Network Protocol

The purpose of this section is to outline the functional requirements of the Aurinko Network protocol. These requirements serve as the foundation for formalizing a real-life protocol in subsequent sections of this paper. Specifically, the protocol must support the following essential functionalities:

1. Privacy-Preserving Leader Extraction Procedure:

   • The protocol should include a privacy-preserving leader extraction procedure. This mechanism is vital for selecting leaders in a way that safeguards user privacy.

2. Permission-Less Access to the Consensus Mechanism:

   • Aurinko Network aims to be open and inclusive. The protocol must allow for permission-less participation in the consensus mechanism, enabling anyone to join the network and contribute to its security and operation.

3. Near-Instant Transactional Finality:

   • Transactional finality is a critical aspect of blockchain networks. The protocol should ensure near-instant transactional finality, providing users with confidence in the completion of their transactions.

4. Transactional Confidentiality:

   • Privacy is a fundamental concern in the digital age. The protocol must support transactional confidentiality, allowing users to conduct transactions without revealing sensitive information to unauthorized parties.

5. Quasi-Turing Complete State Transition Function with Native Zero-Knowledge Proof Verification Capabilities:

   • To support a wide range of applications and smart contracts, the protocol should offer a quasi-Turing complete state transition function. Additionally, it should natively support zero-knowledge proof verification capabilities to enhance security and privacy.

We define an idealized abstract protocol as P_ideal_E, instantiated within the environment E. In this context, E is responsible for managing communications with participants of P_ideal_E. E is assumed to adhere to the protocol rules, possess unlimited computational resources, and have omniscient knowledge (i.e., E has access to the internal state of every participant of P_ideal_E).

Interactions between protocol participants and E follow the request-response communication method, a common approach in distributed system protocol literature. The communication channel between a protocol participant, denoted as i, and E is considered secure. Participants initiate requests by communicating a message (Req) to E, and E responds with a message (Res). P_ideal_E supports the following Req and Res message types:

1. REGISTER:

   • A message type for requesting E to generate a new key pair (sk, pk) and register a new account.

2. SEND:

   • A message type for requesting E to facilitate the transfer of a defined number of native tokens to a specified public key (pkr) of the recipient.

3. CREATE:

   • A message type for requesting E to create a new application (Application). Applications are assumed to have diverse functionalities and can interact with each other. Their state is generally accessible to protocol participants, with exceptions for specific functionalities like asset transfers, voting, dividend claims, etc.

4. CALL:

   • A message type for requesting E to execute a call to a specific application (Application).

Furthermore, each request is promptly executed by E, with the outcomes becoming irreversible upon completion.

In this manner, we have outlined an abstract protocol that is well-equipped to accommodate the functionalities outlined at the beginning of this section, providing a robust framework for the Aurinko Network protocol.