Goal: get TN data to EVM chains

[markholdex]

Specs

Blocking

• Goal: get TN data to EVM chains #547

Related

• Goal: Blockchain Interoperability Framework #444

Problem:

• trufnetwork/truf-data-provider#337
• Problem: Timeout When Retrieving Data via ChainLink Function #752
• Problem: Smart Contracts Lack Access to TSN Data #721
• truflation/tsn-data-provider#320
• truflation/tsn-data-provider#321
• truflation/tsn-data-provider#330
• truflation/tsn-data-provider#331
• truflation/tsn-data-provider#332
• trufnetwork/truf-data-provider#347
• Problem: missing oracle contract tests #756
• Problem: Oracle contract is not deployed #757

RnD:

• Problem: TSN Team needs to RnD Chainlink Technology #720
• Problem: Serveless Approach for TSN API Adapter #725
• Problem(tsn-sdk): Can't be imported in Deno #733

[markholdex]

@rsoury this is the next goal that we need to begin to spec out. Can you kickstart things with a Google Doc?

[rsoury]

Sure thing - We have a plan, and scope already - however, it likely needs a second pass.

I'll create the doc soon too.

PS. I am in conference mode for Token2049 - so work will ramp up post 23rd of Sep.

[rsoury]

PS. @markholdex - Can you create a priority list of the EVM chains to support?

We can incrementally serve them - ie. if the early ones are fully supported by Chainlink

[markholdex]

@rsoury the ones that want integration with us and are willing to offer a grant are new and not supported by Chainlink. These chains are focused on RWA which is our niche too.

I was thinking if you could explore and spec out multiple solutions that we could do:

1. With chainlink
2. Without chainlink

I will initiate the doc and attach it here for the ease and we can drop the ideas there.

[rsoury]

Note that this is related to #444,

I will need to discuss with Brennan first before we commit to anything concrete - ensuring interop is compatible with existing Kwil plans.

[markholdex]

@rsoury any updates here? I understand that it's related with to:

• Goal: Blockchain Interoperability Framework #444

We should be thinking of the most easiest solution at the moment to satisfy the requriements form Ostium, Overlay, Plume and many other RWA chains that want this data. Overaly is now sourcing our data from Kong.

[markholdex]

It is also related to:

• Goal: TSN webhook #724

[rsoury]

@markholdex - Thanks Mark, I'll have a spec ready by Monday at the latest.

I'll keep the spec simple.
It will not include the verifiability for #444.

[rsoury]

@markholdex - Please share edit access to the Spec with me. Suggestions on Google docs are clunky.

[rsoury]

The Spec is primarily ready for review. Only detailed implementation remaining.

Quite straight forward, a mix of Chainlink and API3 should suffice for now.

@outerlook - Please review the implementation and expand into necessary developments to deliver this. ie. Serverless Function + AWS CDK?

@markholdex - Feel free the review the state of the spec.

[zolotokrylin]

@rsoury, I left a comment in the doc. Please check. P.S. good spec 👍

[markholdex]

@rsoury I also left some comments in the doc. Please have a look. Thx!

[rsoury]

@markholdex - Replied!

[markholdex]

@rsoury replied back.

[rsoury]

@markholdex - I've amended the Spec, and resolved various comments accordingly.

[markholdex]

@rsoury thank you. I reviewed the specs and all is clear to me. Do you want to add anything?

[markholdex]

friendly reminder @rsoury

[outerlook]

is this goal a blocker for #699 ?

[rsoury]

@markholdex @outerlook - Replied.

I do think Functions vs Any API is a trivial matter.
I think selecting the one that seems easier from developer experience is the wisest approach.

[zolotokrylin]

is this goal a blocker for #699 ?

It could be or could be not. Depends on how we structure. I prefer not to make it a blocker.

[markholdex]

@rsoury left you comments in the doc. Please review 🙏

cc: @MicBun @outerlook

[rsoury]

@markholdex - Replied. Think this finalises it.

@outerlook - will review to ensure it's clear.

[zolotokrylin]

Guys, what's left here? Can we start coding?
@rsoury @MicBun @outerlook

[rsoury]

I believe we can indeed start coding @zolotokrylin

[markholdex]

@outerlook @MicBun what is the ETA for this Goal?

[MicBun]

Hi @markholdex, some parts of this Goal need to be researched thoroughly and may take a longer time as we go through trials and errors.

It may take 2 weeks and may be up until 3 weeks

[rsoury]

@MicBun and @outerlook - Please contact me if you have questions/concerns on the Solidity-related stuff.

Syntactically, Solidity is designed to look and feel like Javascript.

[outerlook]

update:

with the last updates, our @trufnetwork/sdk-js is now fully compatible with the Chainlink Functions environment. (see this)

We're heading to the next phase where the concrete smart contract implementation is the objective. However, I see from these specs that the scope is a little bit bigger than what unblocks #699

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.

then, I'll tackle first

• https://github.com/trufnetwork/truf-data-provider/issues/337
  as an example of Sepolia

and based on it we can create a permissionless but billed contract that doesn't block other tasks?

What do you think, this makes sense or it's off?

@rsoury @markholdex

[rsoury]

@Jarryd-pretorius @itscameronlee - A note on Nuon:

We can simply manually whitelist Nuon Smart Contracts directly within the Chainlink Functions UI.
If we proceed with the proposition for off-chain billing added to the Spec, then we should be unblocked for now.

[markholdex]

@outerlook @rsoury @MicBun

The billing aspect will be resolved as part of a separate goal:

• Goal: TRUF Network billing #740

Let's wrap up with EVM chain support only so we can query some streams on-chain. What is the ETA for completion?

[MicBun]

Log: I moved #744 into #740

As for ETA, I think it can be done this week or early next week.

[outerlook]

If the goal was just to demonstrate how to deploy on EVM, today would suffice. I need Friday (6th) to deploy more things otherwise.

Details

• yesterday I was able to deploy the example contract with success on sepolia
• I'll wrap up today the code on the PR
• This example contract is exclusively to pave the way on how to bridge data from TN:
  • requestTNData is owner only, no whitelisting mechanism
  • Hardcoded to use get_record procedure
  • returns pure string (may not be useful for EVM?)

Given this, it would suffice if the goal is to demonstrate the ability to bridge data into EVM.

But I'm understanding that even without the billing mechanism, we will be the ones to manage the contract, correct?

Then I need at least until Friday (dec 6) to have:

• upgradeable contract
• whitelisting mechanism
• more flexible requestTNData
  • allow for different procedures
  • return uint256 (maybe just multiply by 10^18 to eliminate our decimals)

it will still leave out:

• other EVM chains (only sepolia), as funds and other concerns need to be addressed unless is a requirement for this goal
• more secure upgrade mechanism (multisig?)
• more complex data manipulation and constraints as not to create solutions before problems

[markholdex]

@outerlook can you post your progress in the relevant problem?

• https://github.com/trufnetwork/truf-data-provider/issues/337

[MicBun]

Log: moved billing-related info from specs from
#547 to #740

[outerlook]

update: I'll have to extend my ETA -- Next Wednesday (Dec 11)

Details

The contract itself, unless reviewers disagrees, is basically done here.

The happy path of the contract is manually tested, but before deployment I strongly recommend us to at least have some automated tests done for the contract.

I split the task into smaller ones to accommodate these tests and deployment separately.

Why isn't fully upgradeable?

• Dynamics with Chainlink Functions and our consumers contract are making it wiser to go for a non-upgradeable contract. This will make the process leaner and, principally, way more secure.
• If upgradeability is a requirement in the future, it would demand:
  • more work on adapting ChainlinkFunctionsClient to support UUPS (they don't support natively yet) for safety
  • define someone to be responsible for the private key and deployment

but it might not be necessary, IMO.

It's still fair enough upgradeable for development: source code and some important states are controlled by roles that can be renounced.

As soon as possible, each role should be renounced. To update our contracts, we would then publish new versions.

[zolotokrylin]

@outerlook thank you for the update regarding ETA.
Do you mind leaving technical updates directly in the relevant Problem issues, please?

[markholdex]

@outerlook do we have any updates on the ETA?

[outerlook]

Yes, the new ETA for deployment is today (Dec 12th)

(Sorry, I left this eta update as a Draft and forgot it seems)

[outerlook]

Embarrassingly needing an extra day on this. I'll leave an extra note on the deployment issue

[outerlook]

(publishing to the goal as I think it might be the expected outcome from here, right?)

• The contract has been deployed on sepolia
• there's an initial, but comprehensive docs available on how to consume

Can we dettach this issue, as downstream goals will be unblocked?

• Problem: contract ownership not transferred #758

I think the above issue needs some discussion yet (maybe transform into a goal)
The current state is that our contract is a partially upgradeable so we can iterate during the next phases, and I have the roles to control it. But we need to remember not to put values that depend on this data until I may either transfer the roles to someone or renounce them to make them entirely immutable.

[zolotokrylin]

@markholdex stakeholders are notified in slack about completion?

[zolotokrylin]

make sure the iteration is correct

[markholdex]

@markholdex stakeholders are notified in slack about completion?

just notified. Thx for reminder.