Loading of configuration values from a file while starting any network or sputnikvm

[harishbm34]

We are implementing an "InterChainTransaction" precompiled contract to verify the transaction (tx1) which has happened on the "Ethereum Blockchain" during the ICO.

Once we are on the MAINNET, to verify the transaction (tx1), which was occurred on the Ethereum blockchain, we were hard-coding the "https://mainnet.infura.io/v3/{API-Key}" url inside the code. But we would like to keep these values somewhere in the configuration file, so that we can avoid the recompilation even though if we change the "URL" later.

Can we please have this feature in the "sputnikvm" so that it will help us a lot.

Kindly revert me in case if it requires more clarifications.

Regards,
Harish Belavadi

[mersinvald]

@harishbm34 do you want an arbiatry Environment storage attached to the precompiled contracts?
So the config file would be loaded at the init phase and then used from within your precompiled contract?

To figure out how we could approach that I need some info:

• Are you using SputnikVM as a library or as a cli app?
• Do you need any special config format requirements?
• Would you rather process the config in your own "init code" or the global sectioned config shared among all precompiled contracts via key-value like storage would work for you?

Also, how many fields are you expecting to store in such configurable storage?
If there is just a URL, using environment variables seems like a simpler and better option to me.

export MAINNET_URL=https://...

let url = env!("MAINNET_URL").expect("MAINNET_URL is unset");

[splix]

@harishbm34 can it be passed through an initialization function, which will be called before first run? I doesn't change the fact that the contract should store it somewhere, but it would be better fit for the logic of contract.

All components should expect that same code with same inputs (call input and current state) will always produce same output. Execution should be deterministic.

So this configuration variable should be part of state, it should be clear that changing URL will affect results.

[splix]

If you precompiled contract makes external calls to that URL, I would also suggest to change the execution flow to more deterministic, which for that case would be 1) requesting an URL, as a method call 2) your external code immediately makes a request, and provides results as a separate call. That would be Oracles pattern, and all non-deterministic execution are clearly defined outside of smart contract execution, we can guarantee that for same data provided on step (2) you'll get same results of execution.

[harishbm34]

@mersinvald : We are using SputnikVM as a library in our blockchain.

@splix : That's very good question. Let me explain why we need to have configuration file within the initialise phase of loading SputnikVM and why we can't use another Call method to get the URL.

What we are looking is simply verifying a transaction inside the Ethereum blockchain. After verifying transaction we can claim GTX token in our blockchain automatically.

To claim GTX token user needs to send 2 transactions.
Tx1 happens in the Ethereum blockchain to freeze the gtx token inside the ERC20 contract.
Tx2 happens in the Gallactic blockchain to verifying Tx1 through its hash and claiming exact amount of GTX token inside Gallactic blockchain.
It’s kind of checkpoint for tx1.

If we use another call to get URL of an Ethereum node then we will have a deterministic and unique url through all nodes of our blockchain, So in this case: if all the node connecting to a same Host, then there should be a potential risk of attacking the same node to manipulate the transaction data. Even they can make the node unreachable by DDoS attack.

In the other hand, if each node can connect to the different node (or nodes) in Ethereum network, since the Ethereum transactions are immutable and deterministic, the result of the pre-compiled contract also would be deterministic as well. However some full nodes in our Galalctic blockchain might run the full node of Ethereum blockchain locally so they locally connect to the Ethereum blockchain.

What we can suggest is adding a init_patch or load_config method to the patch trait. The result can be a Boolean. In case of any any failure the VM won’t initialised and therefor the node won’t start. We can check the URL validity at the init phase by calling web3.version method.

If you are agree about adding this new method to the patch trait we can handle it here.

[harishbm34]

@mersinvald @splix : Shall we get an input for the above concern.

[splix]

Sorry, I missed your response.

As we both see, there're few different ways to have such external calls, and one proposed by me is more complex. At this moment it's just something we'd like to have in future, but right now it will require a lot of work. If you think your way is deterministic for your use case, it's fine then, considering that it's an external implementation anyway so it doesn't conflict with possible other implementations, and it will be great to have it.

If you can implement such initialization via config, we'll appreciate if you make a pull request, with changes related to SputnikVM side. I hope it's possible to make such configuration flexible and usable for other precompiled contracts