The calldata
storage is just the trick for writing down some information on the blockchain. Usually, you use the calldata
to pass some arguments to a contract method, but in some cases, you want just the fact of providing the data in arguments to be enough, for example - the layer 2 can pass continuously its checkpoint information to provide their verifiable state. To read this data offchain, you query the last transaction to the contract's method, and the input data is the information you are looking for. By fetching all that transactions, you get the history/full data.
Some -/+
of this method
-
you can't store information in the calldata if you generate this information within the contracts method.
-
difficult to fetch or filter. You fetch the transactions first and then process the data.
-
not accessible later within the contracts method in other transactions
+
the cheapest way to "store" the information.
How to store the Data? Simply submit a method-call transaction. Similar as Danijel has shown, but you don't process the values:
contract IPStorage {
function storeIPAddresses(string[] calldata _ips) public {
}
}
To access the data off-chain you will need a 3rd party service, which can give you all transactions by to
and method signature
filters, or you index the transactions on your own.
Another way to "store" the data is by using the Logs
, which costs more gas:
+
you can store information in event-parameters created within the contracts method.
+
easier to fetch or filter by using eth_getLogs
RPC call
-
not accessible later within the contracts method in other transactions
Real storage solves all the minuses but costs more gas.
You can mix all of this "storage" types to save on tx
fees and to solve your usecase.