trufnetwork / trufnetwork/node

Problem: Truf Network need to own Solidity Smart Contracts

Open
#744 5 comments 1 reaction 2 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
7
Forks
3
Avg merge
3h 2m
Merged PRs (30d)
13

Description

If I understood the specs correctly, the scope is also to propose a permissionless initial billing strategy, whereas, on Nuon, it could be a contract whitelisted for the Nuon owner/consumers, which simplifies.

@outerlook - after a little looking, and since we proceeding with the CF approach, we're going to need to create our own Solidity Smart Contracts.

This is primarily because CF has a whitelisting mechanism for "consumer" contracts.
Furthermore, there's a cap of 100 "consumer" contracts.

Therefore, our new contract will be a single "consumer", that allows for any number of calling contracts to request Truf data.

The function of these Contracts are to:

  1. Proxy incoming calls from foreign contracts to Chainlink
    1. Here, calling contracts must transfer TRUF tokens to the Proxy in order to facilitate the Chainlink request.
    2. We must ensure this Proxy is funded with LINK tokens too.
    3. The TRUF token will remain in the Contract - but there must be a Administrative function to withdraw these tokens to a wallet that is predetermined by the Admin. ie. Admin wallet can only trigger a function to withdraw to a SAFE multi-sig.
  2. Facilitate billing dynamics.
    We can either use a hook paradigm where upgradeability is only enabled on the hook contract, or we can couple the contracts and make them both upgradeable.
    The latter is a little less secure, but we're going to need to manage security around Admin keys anways.
    I think zero-trust Admin mechanisms are required - I have plans for this, but in the meantime, there should really be only a single person with access to the Admin wallet....
    Or better yet, we make the SAFE wallet that is designated to receive the TRUF tokens as immutable...

@Jarryd-pretorius - What's your take on this?
Zero-trust protocol around key management is something I can propose, but do you have suggests for interim security processes around super-sensitive key management (ie. Contract Admin)?

The best approach to execute this is for Raffael or Michael to try their hand at the Solidity Contracts.

Then I'll review the Contracts before we deploy them.

Additionally, these Contracts will need 100% unit test coverage (ideally in Foundry, but can also be in Hardhat)
Furthermore, deployment scripts are necessary for the Contracts.


Alternative 1: We manually whitelist "consumer" contracts (customers) to use our CF Oracle.
The customers essentially pay us off-chain, and use LINK to execute directly against Chainlink Contracts.


Alternative 2: Giving the CF code to customers to deploy themselves... essentially handing over Serverless Oracle management.


Of course, the first strategy gives us more control over automated TRUF powered billing of data across Chains... but has more technical overhead.

Originally posted by @rsoury in https://github.com/trufnetwork/node/issues/547#issuecomment-2505016845

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.