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().
Related
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.
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 have been struggling for quite some time with finding an explanation to what events are in Solidity (or in the Blockchain context). As far as I understand, they are a way of storing (or logging) information on the particular contract that can then be updated throughout the life of that contract. But how is this different than a plain ol' variable? Why can't I just create a variable that is then simply updated with new information?
Events in Solidity can be used to log certain events in EVM logs. These are useful when clients are required to be notified of any change or event in the contract. Or maybe in the future you need to search for something that has happened so you go through all the logs. These logs are stored on the blockchain in transaction logs. Logs cannot be accessed from the contracts but are used as a mechanism to notify change of state or the occurrence of an event in the contract. They help us write asynchronous applications.
Events are stored in the logsBloom which is in the header of each block.
Events are piece of data executed on the blockchain and stored in the blockchain but not accessible by any smart contracts. it is kinda console.log in javascript or print in python.
Events are much more gas efficient than using a storage variable
Events are useful for testing the contract. If you interact with oracles, you sometimes want to see if the function call by oracle service is done or not. To see if the function call is done, you emit the result of the function or one of the properties of the result.
Events are useful if you want to maintain the history/log of every change that happens in a mapping.
Deposit contracts were created on the Ethereum 1.0 chain. This kind of smart contract is used for depositing ETH on the beacon chain. An event is emitted every time a deposit is made.
There are two events that must be present in an ERC-20-compliant token:
Transfer : This event must trigger when tokens are transferred, including any zero-value transfers. The event is defined as follows:
event Transfer(address indexed _from, address indexed _to, uint256 _value)
Approval : This event must trigger when a successful call is made to the approve function.
event Approval(address indexed _owner, address indexed _spender, uint256 _value)
You can read this article for deep dive: transaction-receipt-trie-and-logs-simplified
From the docs:
Solidity events give an abstraction on top of the EVM’s logging functionality. Applications can subscribe and listen to these events through the RPC interface of an Ethereum client.
It's easier for an off-chain app to subscribe to new event logs than to a variable change. Especially when the variable is not public.
Same goes for querying historical event logs (easy through the JSON-RPC API and its wrappers such as Web3 or Ethers.js), vs. historical changes of the variable (complicated, would need to query a node for each block and look for the changes proactively).
Example: The ERC-20 token standard defines the Transfer() event. A token contract emits this event each time a transfer (of its tokens) occurs. This allows a blockchain explorer (or any other off-chain app) to react to this event - for example to update their own database of token holders. Without the event, they would have no way (or a very complicated way at least) to learn about the transfer.
Solidity events are pieces of data that are emitted and stored in the blockchain. When you emit an event it creates a log that front-end applications can use to trigger changes in the UI.
It's a cheap form of storage.
You can define an event like this:
event Message(address indexed sender, address indexed recipient, string message);
and emit an event like this:
emit Message(msg.sender, _recipient, "Hello World!");
Read this article for more information and this one to learn how to get events in JavaScript using Ethers.js
Should I pay for every read from NEAR protocol?
How do I view the value stored in NEAR protocol smart contract? (e.g. staking pool fees)
What is the difference between view and change methods?
Should I pay for every read from NEAR protocol?
TL;DR: No, you should not.
In NEAR protocol there are to ways to interact with smart contracts:
Submit a transaction with a FunctionCall action, which will get the specified method executed on the chunk producing nodes and the result will be provable through the blockchain (in terms of near-api-js these are "change methods")
Call query(call_function) JSON RPC method, which will get the specified method executed on the RPC node itself in a read-only environment, and the call will never be recorded/proved through the blockchain (in terms of near-api-js these are "view methods")
You can change the state and chained operations (e.g. cross-contract calls, tokens transfer, or access key addition/deletion) only through the first approach since blockchain expects the user to cover the execution costs, so the user should sign their transaction, and they will get charged for the execution.
Sometimes, you don't need to change the state, instead, you only want to read a value stored on the chain, and paying for it is suboptimal (though if you need to prove that the operation has been made it might still be desirable). In this case, you would prefer the second approach. Calling a method through JSON RPC is free of charge and provides a limited context during the contract execution, but it is enough in some scenarios (e.g. when you want to check what is the staking pool fee, or who is the owner of the contract, etc).
Im trying to create a function or an extrinsic that doesn't have a transaction fee for the origin, but rather totally free. I thought maby with a weight of 0 it would be solved but it still costs tokens,
#[weight = 0]
then i tried to adjust the state with an rpc call, which did some calculations but did not modify the state
How can i create a function/extrinsic that is free without any transaction fee? And is it possible for rpc calls to adjust the state?
This is actually very easy with Substrate.
You simply pass Pays::No to the weight of the function.
Like so:
#[weight = (100_000, DispatchClass::Normal, Pays::No)]
Here the tuple describes:
The weight of the function. You should put a real value here to represent how complex this function is for your blockhain's computation.
The DispatchClass of this function. The default choice is Normal
The Pays option which determines if the caller will pay a fee or not.
Note that if you create an extrinsic that a user does not pay any fees, your blockchain is immediately vulnerable to DDOS attacks, as any user could spam this function at no cost.
You will need to build other layers of verification at your blockchain to make sure only valid calls to this function are propagated to other nodes.
Take a look here:
https://github.com/paritytech/polkadot/blob/master/runtime/common/src/claims.rs#L386
In this case, we have some statement which we verify is correctly signed by the user making the call before the call is passed to other nodes:
https://github.com/paritytech/polkadot/blob/master/runtime/common/src/claims.rs#L592
So you must do the same if you want your blockchain to be safe with a free function like this.