I have developed smart contract running on Cronos Chain.
But while testing in bsc test net, Possible to generate random using chainlink oracle.
But to test on cronos chain, I didn't find VRF coordinator address.
I found chain link token address in Cronos chain. But others like VRF coordinator address, hash, fee, I couldn't find.
Please reply if you have experience with this.
Related
I know that VRFCoordinatorV2Interface is an interface and we put the respective chain coordinator address in it. what does it signifies and how to visualise it.
OR
What will be the outcome when we put an address in a interface.
The Chainlink VRF Coordinator is a contract that is deployed to a blockchain that will check the randomness of each random number returned from a random node.
By putting "its address in an interface" you can programmatically interact with it from your smart contract. In other words, the function of your smart contract can call some other function from the VRF Coordinator function, like for example createSubscription().
I'm trying to find some information about the security of using Chainlink as a tool for external API calls. The following is my scenario
My smart contract initiates API call using Chainlink with some parameters
Node picks up the request, does external call
Node receives response from API
Node writes result back to my smart contract
My smart contract finishes the execution
How can I validate that the Chainlink node does not change any of the parameters in step 2-4? Is there some mathematical validation like we have with the blockchain that I can confirm?
The questions comes up because of regulatory requirement that I have and it would be nice if I could simply link to some proof that data cannot be manipulated by a Chainlink node or if manipulation is possible, what could I do to validate the data was not manipulated and/or lower the chance?
I want to know if there's a concept similar to Meta-transactions in Substrate.
"A meta transaction is a regular Ethereum transaction which contains another transaction, the actual transaction. The actual transaction is signed by a user and then sent to an operator or something similar, no gas and blockchain interaction required. The operator takes this signed transaction and submits it to the blockchain paying for the fees himself." 2
You can learn further about meta-transactions in Ethereum from these articles:
Ethereum Meta-Transactions 101
How to implement generalized Meta-transactions?
I want to implement a substrate pallet where I can airdrop certain amount of tokens native to the substrate blockchain and let users with 0 balance claim according to their interaction with some other protocols built on other blockchains.
I researched some feeless mechanisms in Substrate and built a feeless pallet inspired from tutorials by Shawn tabrizi so that my pallet could send balance to users for a certain transaction. But I don't see how I can best implement this mechanism without risking a sybil attack on the blockchain. In ethereum, due to the concept of meta-transactions, it's pretty easy to onboard new users to a certain protocol. What's a possible equivalent case in Substrate for onboarding non-substrate users to a new substrate blockchain?
The Chainlink VRF documentation section is a bit meager as of today, I was wondering whether there is any merit for smart contract developers to allow for Chainlink VRF consumer contracts configuration parameters to change in the future, such as the LINK fee (due to the VRF oracle).
P.S. I was asked by the Chainlink team to turn this doubt into a stackoverflow thread
parameters like VRFCoordinator contract and public key of the VRF node won't change often, if at all with the current version of VRF.
Take note though that in an upcoming improved version, there will be more flexibility, which will include dynamic VRF costs based on gas in the response etc
How would one go about building an escrow and multisig contract on NEAR?
E.g. in comparison to building the contract in Solidity; what would be needed, are there any examples?
I can't compare this for solidity. But on NEAR multisig contract can be implemented either using multiple AccessKeys or using multiple predecessors.
The following steps are needed:
Propose an action e.g. transfer X to Y to the contract by calling propose() on the contract. This should return a proposal_id
Aggregate approvals for the proposal_id using approve() or reject() calls.
Once necessary amount of approvals are collected. A caller can call issue and pass the proposal_id, it will issue the action and close the proposal.
Seems there are two questions here, for escrow and multisig. Evgeny has taken on the multisig part.
We do have a simple example of escrow on NEAR written in Rust.
This example has no frontend but provides the lower-level CLI commands needed to show an escrow in use.
https://examples.nearprotocol.com/rust-fungible-token
There is an example of multisig contract now here written in Rust - https://github.com/near/core-contracts/tree/master/multisig
The main benefit and why it becomes way simpler, is that NEAR Accounts already maintain set of keys per account. Contract just needs to manage the requests and execute them when enough confirmation have been received.