Jump to content

Open Club  ·  12 members


How smart contracts function, node participation and multisig on Evernode


Recommended Posts

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:

  1. The XRPL (L1): Primarily value-based transactions (deposits & withdrawals) and encoded messages/instructions via the Memos field.
  2. 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.



5 signers with a fair share of their own voting weight (each signer has a signing weight of 2, the quorum set is 8 and overall voting weight is 10).
For the multisig list's signers to pass a transaction under this account, at least 4 of these collective signers' signatures would be required to pass a transaction.

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.

Author - @wojake
Reviewer - @efFofexX

Link to comment
Share on other sites

  • Replies 0
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

  • Create New...