# Hollow/Hyper BEAM

## Summary

The Hollow BEAM (HB) is a scalable, complete, and useful SmartWeave network that employs Deterministic Compute, Stateless Messages, and the Permaweb Payment Protocol to create a scalable smart contract network. The system comprises several components, each of which communicates with each other through a message protocol. This protocol allows individual processes (smart contracts) to interoperate without a shared global state, addressing one of the main challenges in Smart Contract Networks: interoperability and shared state.

Imagine a network designed akin to the "Actor" pattern, where each "Contract" operates as a process. Each process can receive messages and return messages placed in an outbox, allowing contracts/processes to be isolated from one another. This way, they can focus on their individual rules.


## Problem/Challenge List

- Stake Weight Attacks
- Liquidation Bots and Updates
- Financial Risk Semantics
- Process Spawning
- Sequencer Scalability
- P3 Channels
- Self-Hosting
- MINT
- Message Format
- Test Infrastructure

## Components

The HB system is composed of the following components:

- Messages
- HB Smart Contract
- HB Contract Library
- DRE (Dedicated Resolution Environments)
- Relayer
- Fisher
- Sequencer
- Gateway
- Registry (Arweave)


### Messages/Data-Entries/Transactions

The protocol message consists of a set of data containing a caller, a target (Process), and an action (instruction set). For example, the message could be an action requesting to transfer a unit from the caller to a wallet or contract address. This message would traverse through HB to the relevant process identified by the target and be evaluated by a DRE, which will return a result. This result will consist of `ok|error` and `0 to infinite messages`.

### Sequencer

The sequencer is in charge of receiving the messages/data-entries/transactions and establishing a consistent processing order within the HB system. In addition to managing the ordering, the sequencer is also responsible for writing these messages/data-entries/transactions to `Arweave`.

### Gateway

The gateway is a publish/subscribe service that accepts messages/data-entries/transactions from the Sequencer and publishes them to any system listening - these systems being the DREs (Dedicated Resolution Evaluators).

### DREs (Dedicated Resolution Evaluators)

A DRE is a server that subscribes to the gateway and receives ordered messages/data-entries/transactions. If any of these items belong to one of the processes that the DRE is managing, it accepts the message and passes it to the process. This "Process" is the "Smart Contract", which specifically looks for messages and evaluates these messages against the "State" of the Process.

The action contains the `caller` and `input`, and the state is the current state since the last evaluation.

const {state, messages, status} = handle(state, action)

### Relayer

The relayer is a service that locates messages in the outboxes of processes and sends them to the sequencer for processing. In the messaging system, a process could produce 0 to many messages for other processes. The relayer reads the outboxes and sends the messages to the sequencer.

### Hollow/Hyper Beam Contract

The Hyper Beam contract maintains the stake commitments within the system and is responsible for penalizing `DREs` and `Relayers` that are not behaving correctly. This contract can receive messages to deposit or stake an amount of `X`, enabling a user to participate in the network.

### Hollow/Hyper Beam Lib

This is a Rust Library that provides the specific functionality needed to manage messages on HB. As "Processes" evaluate messages, they need to ensure the caller has enough "STAKE" to process the message. Also, the HB contract will need to verify messages were signed appropriately.

### Fisher

The fisher is a type of validator responsible for verifying the proper flow of messages between snapshots. Each fisher should be able to take the messages between one snapshot and another and verify a proof that the messages were evaluated in order. If the proof is incorrect, the fisher can call the HyperBeam contract requesting to slash a relay that is not acting correctly.

### Registry

The registry system is a list of Data-Entries that map a process to a specific DRE. This registry is used to manage the discoverability of the DREs for the relays and users to access a Process's outbox or state.

## The Crank

In the message process paradigm, a process/contract cannot use `contractReadState` or `contracts.write` to interoperate with other contracts/processes. Instead, the process/contract must publish a message asking for data from another process, and manage an internal request queue. When a new message arrives, the process can resume the original task that a user invoked.

For example, when a Marketplace Contract wants to settle the exchange of an order, it will need to create two messages. One message to send the buyer the Asset they purchased, and another message to send the seller the token used to purchase the asset. These messages are placed on the outbox of the MarketPlace contract. The relayer will read these messages and dispatch them to the Sequencer, the sequencer will order the messages and write them to the Arweave Network as well as dispatch them to a publish/subscribe service (HB Gateway). The HB Gateway will broadcast the messages to all listening DRE nodes. The Asset DRE will consume the Asset transfer message and deliver it to the Asset Process that will update the existing state and publish a Delivery Notification message in its outbox. The Token DRE will consume the Token transfer message and deliver it to the Token Process that will update the existing state and publish a Delivery Notification message in its outbox.

This process of message passing to relayer, to sequencer, to DRE, to Process is known as the crank system. For each of these services to perform their microservice, the request system needs to fund the P3 relayer, which in turn funds each service in the system for successful interaction.


## Initial Plan

The initial plan is to build HB alongside the Warp Architecture, with minor adjustments to the Warp DRE as a pull request. A Rust Library will handle the message semantics and Warp SmartWeave Contracts in Rust will handle the HB Contract, WrappedU Contract, and the UCM Contract.

### Phase I - Proof of Concept (Proposal)

The aim is to build a Relayer/DRE that manages the HB Contract + HB Lib. This project will identify the internal semantics of the system without the complexity of running multiple systems. The goal is not to create a production deliverable, but to help identify requirements for the Relayer, DRE, HB Contract, and HB Library using NodeJS, the Warp SDK, and Rust Contracts.

The system should be able to consume messages from the sequencer as if it were a gateway and dispatch these messages to the internal DRE component that submits them to the process for evaluation. The process will then generate results that include new messages to

be read by the relayer and dispatched to the sequencer.

This POC should demonstrate message passing for STAKING and Transfering a Token balance from one wallet to a contract and transferring the Token balance from a contract to another wallet.

(A diagram here to visualize the flow of the POC would be helpful)

### Phase II - Alpha

This phase involves building a production system leveraging the Warp architecture and minor augmentation to the Warp DRE to support outbox messages. Components to be built include the Relayer and the Fisher, while the DRE will be augmented with a PR submitted to Warp to support `outbox messages`. The Sequencer and Gateway will remain untouched. Modules such as the Registry, P3 on DRE, and P3 on Sequencer can be implemented in the next phase.

### Phase III - Scalable Sequencer

In this phase, we aim to implement P3 across the services and build a scalable sequencer that uses the HotSpot2 leader system and the Solana multi-threaded sequencer algorithm (dubbed the SolHotWeave Sequencer).

[Need a better diagram here]


# Glossary

1. **Hollow BEAM (HB)**: A scalable, complete, and practical SmartWeave network employing Deterministic Compute, Stateless Messages, and the Permaweb Payment Protocol.

2. **SmartWeave**: A blockchain protocol that allows developers to easily deploy 'smart contracts' - programs which can be triggered by transactions to modify the state of a contract.

3. **Permaweb Payment Protocol**: A protocol for enabling payments on the permaweb, which is a permanent, decentralized web built on the Arweave network.

4. **Actor Pattern**: A model that treats "actors" as the universal primitives of concurrent digital computation. In this context, each contract is viewed as an "actor" or process that can receive and send messages.

5. **Sequencer**: A component responsible for receiving messages/data-entries/transactions and establishing a consistent processing order within the HB system.

6. **Gateway**: A publish/subscribe service that accepts messages/data-entries/transactions from the Sequencer and publishes them to DREs.

7. **DRE (Dedicated Resolution Environments)**: A server that subscribes to the gateway and receives ordered messages/data-entries/transactions. If a message belongs to one of the processes that the DRE is managing, it accepts the message and passes it to the process.

8. **Relayer**: A service that finds messages in the outboxes of processes and sends them to the sequencer for processing.

9. **Fisher**: A type of validator responsible for verifying the proper flow of messages between snapshots. The fisher can identify bad messages and submit a proof to have an invalid relayer or DRE slashed.

10. **Registry**: A system that is a list of Data-Entries mapping a process to a specific DRE.

11. **The Crank**: The process of message passing from relayer, to sequencer, to DRE, to Process.

12. **HotSpot2 Leader System**: A system used in the scalable sequencer for handling network tasks. [Additional context needed for accurate definition]

13. **Solana Multi-threaded Sequencer Algorithm**: An algorithm used in the scalable sequencer for processing tasks. Solana is a high-performance blockchain that supports smart contracts.

14. **P3**: A term used in this context to refer to a specific funding mechanism for different services in the system. [Additional context needed for accurate definition]

15. **Warp Architecture**: The architectural design of the Warp network that the HB is built alongside.


16. **POC (Proof of Concept)**: A small exercise to test a design idea or assumption.

17. **Rust**: A multi-paradigm, high-level, general-purpose programming language designed for performance and safety, especially safe concurrency.

18. **NodeJS**: An open-source, cross-platform, back-end JavaScript runtime environment that runs on the V8 engine and executes JavaScript code outside a web browser.

19. **SDK (Software Development Kit)**: A collection of software tools and programs used by developers to create applications for specific platforms.

20. **STAKING**: The act of holding funds in a cryptocurrency wallet to support the operations of a blockchain network.

# Appendix - Example Flow

1. **Staking**: The seller, let's call them DMac, stakes some amount of HyperCoin on the HB Contract. This is essentially a deposit which allows DMac to participate in the network.

2. **Transfer Asset to UCM**: DMac then transfers the digital asset they want to sell to the UCM (Universal Contract Manager). The asset transfer is done via a message sent through the HB network.

3. **Create Order**: Once the asset is transferred, DMac creates a limit order on UCM specifying the price of the digital asset in tokens. This action is also done via a message.

4. **Buyer Staking**: Now let's say Sam, who is interested in buying DMac's asset, also stakes some amount of HyperCoin on the HB Contract, allowing him to participate in the network.

5. **Transfer Tokens to UCM**: Sam then transfers the required amount of tokens to UCM, which is the price set by DMac for the digital asset. This transfer is also facilitated by a message through the HB network.

6. **Create Market Order**: Once the tokens are transferred, Sam creates a market order on UCM to buy the digital asset. The creation of a market order is done through a message.

7. **Exchange Execution**: At this point, the UCM, upon receiving the appropriate messages, will facilitate the exchange. The digital asset from DMac is transferred to Sam, and the tokens from Sam are transferred to DMac.

8. **Completion**: After the exchange has been completed, Sam unstakes his HyperCoin on the HB Contract.

Throughout this process, each action triggers a message that gets sent through the HB network. Each message is received and processed by the appropriate process (smart contract). The result of processing a message can also generate new messages, which are then relayed through the network for further processing.