Search the Community
Showing results for tags 'hotpocket'.
Abstract HotPocket smart contracts hosted on Evernode are layer-2, thus making them function and interactable on 2 different networks. HotPocket smart contracts operate on their own respective cluster of 3rd party hosts (nodes), or to simplify: their own independent L2 network built atop of the XRPL. HP smart contracts are therefore interactable on their respective L2 network via websocket as well as on the XRPL via their own XRPL account. There are 2 primary ways to interact with HP smart contracts: The XRPL (L1): Primarily value-based transactions (deposits & withdrawals) and encoded messages/instructions via the Memos field. The contract's cluster (L2): Interactions between the cluster's nodes via websocket, allowing you (as a user) to call functions, compute and key-in data on the smart contract. The smart contracts' code, state and execution of their code are not performed or stored within the XRPL whatsoever but HP smart contracts are interactable on the XRPL as each smart contract would have its own XRPL account controlled by nodes in a decentralized manner using a multisig solution which allows selected nodes to systematically come to agreement on on-chain transactions, making HP contracts truly decentralized on both layers (L1 & L2). XRPL's multisig solution The XRPL has a multsig solution which allows your account to define a list of trusted accounts, which gives them the right to sign transactions on behalf of your account. This feature enables nodes to control a contract's XRPL account in a decentralized manner. A little fact on XRPL's multisig: An XRPL account that has setup multisig features a list of accounts with their own respective voting power/weight and a minimum required quorum value, which if reached, will allow a transaction to be validated successfully on the XRPL. Example: How nodes participate (w/ multisig) Let's make an example environment where a contract has 13 nodes on its cluster: The contract could only have 8 out of the 13 nodes to be included on its XRPL account's multisig list, 5 other nodes will not be having on-chain voting rights on the contract's XRPL account as there could only be 8 signers on a multisig list (unless the ExpandedSignerList amendment passes, which would allow 32 signers to be on a multisig list). If the ExpandedSignerList amendment is enabled in the future, contracts could be much more decentralized and trustless as the custody to their XRPL account would be shared among up to 32 nodes. This would also have the benefit of making it much more difficult to compromise the contract's XRPL account through insecure nodes. If you're a rippled validator and want to see Evernode succeed, vote Yes for the ExpandedSignerList amendment: it helps Evernode as a platform as smart contracts hosted on 3rd party hosts are able to distribute on-chain voting permission to 32 nodes compared to 8 which increases security and the decentralized aspect of contracts. Welcoming all discussions, thoughts and questions on this thread. Credits Author - @wojake Reviewer - @efFofexX
Evernode Evernode is a layer 2 smart contract solution composed from the XRP Ledger. Evernode is a smart contract hosting platform consisting of off-chain nodes that directly run pieces of code, consensus and maintain a distributed, canonical state to provide flexible layer 2 smart contracts to the XRP Ledger. Introduction To achieve layer 2 smart contracts, Evernode combines multiple technologies together to form an off-chain solution that runs in parallel with the XRP Ledger. By operating as an off-chain solution, Evernode is able to have its own platform of nodes dedicated to operate and maintain smart contracts in a permissionless, flexible and scalable manner. This way, Evernode allows more flexible and advanced applications to be built on the platform rather than using lite smart contracts (Hooks) that can only facilitate a limited amount of capabilities within the bounds of the XRPL's native protocol, which was not created with customizability and flexibility in mind. A node on a smart contract cluster is called a HotPocket node, it is a secured container in an Evernode Host which is autonomously managed by a daemon called Sashimono. The daemon has multiple responsibilities such as managing all incoming hosting requests (redeems) and provisioning smart contract instances in secured containers. HotPocket nodes are independent from the XRP Ledger, they're not a part of the XRP Ledger. Diagram 1: An Evernode Host's high level structure (simplified) The Evernode ecosystem consists of 4 parts to fully operate seamlessly: 1. Evernode Hook 2. HotPocket 3. Sashimono 4. The XRP Ledger's native DEX We'll divide these complicated components into different sections and explain it to you in this post based on our own understanding. Evernode's components 1. Evernode Hook The Evernode Hook is one of the most essential parts of Evernode. With Hooks enabled on the XRPL mainnet, Evernode is able to establish an on-chain platform to connect all the participating parties, maintain a governance platform (DAO), and efficiently control the issuance and distribution of Evers to reliable hosts through audits. The Evernode Hook has multiple responsibilities that are crucial to the ecosystem: - controlling the issuance and distribution of Evers - verifying node membership in Evernode - tracking node performance through audits - governing the servicing of smart contract Hosting Requests submitted by L1 Evernode users - maintaining Evernode's configuration parameters All participating parties on Evernode use XRPL transactions with attached memos to incorporate Evernode operation payloads: - Evernode Hosts: host registration/deregistration - Auditors: audit request/results - Evernode users: redeem request/results Utilizing memos allows participating parties to transmit data on the XRPL between each other. For instance, an Evernode Host will create an XRPL account and register to Evernode through the Hook, it'll look something like this: The Evernode Hook defines a set of tunable configuration parameters to govern the rules of the system, which can be changed in a permissionless manner via a governance vote on the XRPL. The following parameters are tunable via the governance system: - max supply of Evers - number of Evers rewarded per Moment - number of ledgers per Moment - host registration fee - max number of ledgers within which a redeem request has to be serviced - number of maximum hosts that can be audited by an Auditor per Moment - and much more... 2. HotPocket HotPocket is a UNL-based consensus engine. It manages all consensus related matters in a smart contract cluster with other nodes to maintain a distributed, canonical state of a smart contract. HotPocket allows smart contracts to operate within their own independent cluster with its own chain history and with its own set of nodes. This results in smart contracts being flexible as clusters may be configured to consist of a specific type of node to best fit their smart contract and its intended use case. Diagram 2: Evernode Hosts that are hosting the same 3 smart contract instances Each smart contract cluster operates independently and does not interfere with other clusters. 3. Sashimono HotPocket converts any number of nodes into a smart contract cluster. The rollout of a HotPocket smart contract currently requires manual setup of a smart contract instance in each participating host, which presents scaling issues. From a production standpoint, it's preferable to dedicate a selection of servers for the collective purpose of running logical nodes from various different HotPocket contracts from time to time, and then coordinate these from a unified and decentralized command point. Without Sashimono, HotPocket is a centralized smart contract solution. Generally, a single actor would be required to spin-up and configure the relevant nodes in a smart contract cluster. Sashimono is the daemon that allows smart contract clusters to be spun up in a permissionless and scalable manner without needing to manually setup a smart contract instance in every participating node. 4. The XRPL's DEX The XRPL’s native decentralized exchange (DEX) plays a central role in how users and Evernode Hosts interact with one another, enabling the exchange of hosting services for units of value. Since each Evernode Host will offer its own unique set of performance characteristics fit for various use-cases, there needs to be a way for the market to distinguish the value of services offered by each Host. Evernode facilitates the differentiation of services each Host provides in a novel way through the use of Hosting Tokens, the value of which is determined by the free market on the XRPL DEX. Hosting Tokens are non-divisible tokens minted by Evernode Hosts which can be redeemed in exchange for the services offered by the Host that minted them. The following steps are a high level summary of the flow and lifecycle of Hosting Tokens within the Evernode ecosystem: 1. Hosts mint Hosting Tokens and list them on the XRPL DEX 2. Users exchange $EVRs for Hosting Tokens 3. User sends Hosting Tokens with memo describing instance requirements to the Hook 4. Upon observing the user’s transaction to the Hook, the Host then sends a small XRP transaction to the Hook containing details of the created instance in the memo field 5. The Hook sends the user’s Hosting Tokens to the Host, where the requested computational services are rendered (additional resources can be paid for in Evers) The DEX's Quality Control One important benefit of the DEX is its inherent capacity to police the quality of the nodes via the law of supply and demand. The best signal of a node’s quality and trustworthiness is the natural price discovery of its Hosting Tokens on the DEX. Unreliable nodes should quickly be exposed and their tokens shunned or under-priced relative to their peers' tokens. In this way, the DEX provides an important circuit-breaker function, allowing unreliable or poor quality nodes to be easily auto-identified by dApps and dApp developers. ------------------ Credits Wo Jake - Author effofexx - Reviewer Note: Learn more about Evernode: - Hooks vs Evernode Links and resources: - Evernode Documentation - Evernode Whitepaper v1.0 - Evernode Hook codebase - Evernode Community (Reddit) - Evernode Media (Twitter) - Sashimono's Design