## Summary

Hollow BEAM (HB) for short is a `scalable, complete, and useful` SmartWeave network that leverages Deterministic Compute, Stateless Messages, and the Permaweb Payment Protocol to complete a scalable smart contract network.

The system is made of several components and each of these components communicate with each other via a message protocol that allows each process/(smart contract) to interoperate with each other without having to have shared global state.

> One of the biggest challenges with Smart Contract Networks is interoperability and shared state.

What if a network was designed to be similar to the "Actor" pattern where each "Contract" is a process and this process can receive messages and return messages placed in an outbox. This allows "Contracts"/processes to be completely isolated from one another and they can focus on their rules while other "Contracts"/processes can focus on their rules.

## Problem/Challenge List

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

## Components

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


### Messages/Data-Entries/Transactions

The actual protocol message is a set of data with a caller, a target (Process) and an action (instruction set). For example the message could be an action that is requesting to transfer a unit from the caller to a wallet or contract address. This message would flow through HB to the appropriate process identified by the target and be evaluated by a DRE, which will return a result, the result will be composed of `ok|error`, `0 to Infinate messages`

### Sequencer

The sequencer is responsible for receiving the messages/date-entries/transactions and establishing a consistent order to process within the HB system. Not only does the sequencer manage the ordering, it is also responsible for writing these messages/data-entries/transactions to `Arweave`

### Gateway

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

### DREs (Dedicated Resolution Evaluators)

The DRE is a server that subscribes to the gateway and receives ordered messages/data-entries/transactions, if any of those items belong to one of the processes that the DRE is managing, then it accepts the message and passes it to the process. What is the "Process", the process is the "Smart Contract", that is specifically looking for messages and evaluating these messages to the "State" of the Process.

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

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

### Relayer

The relayer is a service that finds messages in outboxes of processes and sends them to the sequencer for processing. In the messaging system, a process could have a result of 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 slashing `DREs` and `Relayers` that are not behaving. This contract can receive messages to deposit or stake an amount of `X` to enable a user to participate in the network.

### Hollow/Hyper Beam Lib

This is a Rust Library that provides the specific functionality required to manage messages on HB, as "Processes" evaluate messages, they need to make sure the caller has enough "STAKE" to process the message. Also the HB contract will need to verify messages where signed appropriately.

### Fisher

The fisher is a type of validator responsible for verifing 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 successfully where 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 DRE's for the relays and users to access a Process's outbox or state.

## The crank

In the message process paradigm, a process/contract can't use `contractReadState` or `contracts.write` to interop with other contracts/processes, the process/contract must publish a message asking for data from another process, and manage an internal request queue, so 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 Notif 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 Notif message in its outbox.

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

## Initial Plan

The initial plan is to build HB on the side of the Warp Architecture, with very minor adjustments to the Warp DRE as a pull request, a Rust Library to handle the message semantics and Warp SmartWeave Contracts in rust for handling HB Contract, WrappedU Contract, and the UCM Contract.

### Phase I - Proof of Concept

* Build a Relayer/DRE that manages the HB Contract + HB Lib

The purpose of this project is to identify the internal semantics of the system without the complexity of running multiple systems. The intention here 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 to be evaluated, and generate results that include new messages to be read by the relayer and dispatched to the sequencer.

With this POC, we should be able to demonstrate message passing for STAKING, and Transfering a Token balance from one wallet to a contract, and tranfering the Token balance from a contract to another wallet.

Use Case - Exchange an Asset for U

// Dmac wants to sell his Asset

DMac stakes 100 HyperCoin on the HB Contract
DMac transfers 1 Asset to UCM
DMac creates a Limit order on UCM 1 Asset for 10 U

// Sam wants to buy Dmac's Asset

Sam stakes 50 HyperCoin on the HB Contract
Sam transfers 10 U to UCM
Sam creates a Market Order on UCM 10 U for 1 Asset
Sam unstakes 50 HyperCoin on the HB Contract

In this scenario, we want to create a simple frontend application that allows for Arweave Wallet Users to sell their Assets for a Token Price and Arweave Wallet Users to purchase an Asset for a Token amount

We want to perform this process flow using Actor style message passing, no process/contract will have direct read or write access to any process/contract involved.

Deliverables:

* Message Format
* HB Contract
* HB Library
* U Contract
* UCM Contract
* Atomic Asset Contract
* Relayer Protocol Spec
* Developer Documentation

## Phase II - Alpha

This phase will be the building of a production system leveraging the warp architecture and minor augmentation to the Warp DRE to support outbox messages.

#### Components to build

* Relayer
* Fisher

#### Components to augment

* DRE - Submit a PR to Warp to modify the DRE to support `outbox messages`

#### Components we do not touch

* Sequencer
* Gateway

#### Modules that can be implemented in next Phase

* Registry
* P3 on DRE
* P3 on Sequencer

### Phase III - Scalable Sequencer

In this phase we look to implement P3 accross the services as well as build out the scalable sequencer that uses the HotSpot2 like leader system as well as the Solana like multi-threaded sequencer algorithm. (SolHotWeave Sequencer)

---

---

Previous notes

## Summary

HyperBeam is a distributed smartweave system that wraps each contract into a process, this process can run in a network managed by a scheduler. A scheduler owns the sequencer for the process.

> A process should only evaluate a minimum of one interaction up to x interactions from the previous snapshot.

Challenges:

* Host Rotation
* UPID - IP Lookup
* Process Spawning
* Incentives
* Liveness

---

## Send Message

POST /tx

## Host Rotaion

Current leader finds next leader, if current leader is not found we go to the previous leader.
Signature chain is passed to the next leader.

How long can a schedule be a leader? (Snapshot - Leader change)

## UPID - IP Lookup

Can be resolved by using Arweave L1 by publishing a transaction to L1

## Process Spawning

## Incentives

## Liveness

Availability of each Process/Contract is solved by leader elections, where a leader

## Staking Contract

## Payments

----

Notes from July 18

Real-Time Deterministic Scalable Distributed SmartWeave Node (HyperBeam)

Offer a version of SmartWeave that is complete and usable and scalable

IDEA: is to use messaging passing to treat contracts as processes to talk to each other

Each Contract is a process that can pass message

## Components

* Shared Sequencer or scheduler - coordinates sequences of interactions
> [name=Tom Wilson] Could bundlr be used as a shared sequencer? as Bundlr decentralizes then sequencer would decentralized
* Syncer - syncs interactions from arweave
* Evaluator - evaluates contracts
* Persistence - caches state, interactions, aggregates etc
* Trust - staking contract
* ???

## Notes 7/18

> [name=Tom Wilson] Relayers - acting as oracles, sync free, trust on message

* Find scheduler to post the message
* what if scheduler goes down

Sending an receiving a message, when receiving a message you need some problity of success

Big Problem

- Liveness - what if leader is down (one leader per process)
- Leader Election

Process/Contract decides how it wants to handle message guarantees

Tradeoffs

- MEV

- Proof of history VDF
Could be a kind of proof or work

Leader Management

Orderly Transfer

- POST /tx
-
- POST /tx

- POST /tx

Disorderly Transfer

----

- HOST ROTATION
- UID_IDLOOKUP
- PROCESS_SPAWNING
- INCENTIVES
- TX FEES

---

Process features

no readContractState
no evolve
no unsafeClient