You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HotPocket smart contracts are spun up through a cluster of 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 simplified flow:
Tenant purchase lease NFT from host
Host provisions an instance for the smart contract
Host sends the instance's details to the tenant
Tenant sends the contract's bytecode & its files to the host
Host conducts consensus for state transfer and synchronization
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.
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Abstract
HotPocket smart contracts are spun up through a cluster of 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 simplified flow:
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:
![image](https://user-images.githubusercontent.com/87929946/181909333-a320a2e8-a8a4-4410-a28a-61f94cafe760.png)
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:
![image](https://user-images.githubusercontent.com/87929946/181904468-988e183e-f0c8-41ee-8ccb-d4ed372fcbfe.png)
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 - Wo Jake
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.
Beta Was this translation helpful? Give feedback.
All reactions