How smart contract are spun up on Evernode

[wojake]

Abstract
HotPocket smart contracts are spun up through 3rd party hosts, tenants (smart contract deployers) must acquire lease NFTs from hosts to spin up their smart contracts. Hosts would be offering their hosting services on Evernode through lease NFTs which represents an instance on their respective servers that provides computation, consensus participation and disk space for contract state.

High level overview
Smart contracts are spun up in this flow:
1. Tenant purchase lease NFT from host on the XRPL DEX
2. Host provisions an instance for the tenant's smart contract
3. Host sends the instance's details to the tenant
4. Tenant sends the contract's bytecode & its files to the host
5. Host conducts consensus for state transfer and synchronization
6. Hosts configures the contract based on the state and goes autonomous

In-depth details
How tenants acquire lease NFTs
If a tenant finds a host fit for its smart contract, the tenant would first verify the host's registration on Evernode through its ownership of a Registration NFT issued by the Evernode Hook, the tenant would then proceed to purchase one of the host's lease NFT listed on the XRPL DEX for a set amount of price determined by the host early on.

Example transaction, lease NFT bought by the tenant: Buy_Offer Tx here

Once the lease NFT has been acquired, the host's message board service (mb-xrpl) would be picking this up and start provisioning an instance for the lease and increase its occupied instance count on the Evernode Hook by 1: Tx here (Check Memos field)

Internal logs:

For the curious ones: Container 00010000... is the instance, all instances are Docker containers

How bytecode is transferred from tenant to instance
After the lease NFT has been purchased and the instance has been provisioned on the host, the host would send the instance's details to the tenant through an XRPL transaction's Memos field, the details include the instance's user_port, instance size and other details. The tenant must connect to the instance's user port (22600+instance #) via websocket and transfer the contract's bytecode and its contents (files & configuration) to bootstrap the contract.

Example transaction, sent from host to tenant, the contents are encrypted using the tenant's Message key: Tx here (Check Memos field)

After the contract's bytecode and files are stored on the instance, the instance's HotPocket service would connect to its designated peers (referring to the default set UNL during initial configuration) and conduct consensus with other nodes for a state transfer and state synchronization.

How tenants extend their leases
A lease has to be extended by its tenant for the host to continue providing its hosting services to the smart contract. A lease is extended by a tenant sending additional EVR to the host's XRPL account with the lease NFT on the tenant's XRPL account: Tx here

A lease is successfully extended when additional EVR payment is made and the host confirms the lease's extension by sending a transaction to the tenant: Tx here (Check Memos field)

Internal logs:

If a tenant were to fail at extending their lease, the instance's expiry date would be reached and the lease would be terminated, resulting in the instance's deletion and the lease NFT's burn. In order for the tenant to spin up their contract on the same host again, they must repurchase the host's lease NFT and start the whole process all over again.

Credits

Author - @wojake

Please note that this material was written independently, the research done and its contents might be invalid or outdated as time progresses, please DYOR.

Welcoming all views, discussions, thoughts and questions on this thread.