84
The ABI, Application Binary Interface, is basically how you call functions in a contract and get data back.
An ABI
determines such details as how functions are called and in which
binary format information should be passed from one program component
to the next...
An Ethereum smart contract is bytecode deployed on the Ethereum blockchain. There ...
64
ABI stands for application binary interface.
In general, an ABI is the interface between two program modules, one of which is often at the level of machine code. The interface is the de facto method for encoding/decoding data into/out of the machine code.
In Ethereum, it's basically how you can encode Solidity contract calls for the EVM and, backwards, ...
55
Summary
Your original contract code would not work correctly until I added a constant to the function definition to indicate that this function does not modify the blockchain.
I had to use the method signature of double(int256) instead of double(int) to get the eth_call JSON-RPC to work.
The Details
Run Your geth Instance
You can use the Testnet ...
answered May 2 '16 at 22:22
The Officious BokkyPooBah
32.7k9 gold badges97 silver badges171 bronze badges
26
The JSON is called an ABI.
You do need the source code, as you have, and one way to get the ABI is to paste it in Solidity Browser, then copy the Interface value.
20
Thank you K.Fichter for the help, I just want to fully clarify the answer for anyone else who may run into this issue.
Let's say you want to get the balance of a token at an Ethereum Address. Using Web3 you would do the following:
var tokenContract = web3.eth.contract(contractABI).at(contractAddress)
var decimal = tokenContract.decimals()
var balance = ...
19
It is quite complicated to get this correct, but here's some information on how to work it out.
I'm using a simple contract as an example:
pragma solidity ^0.4.2;
contract Test {
uint256 public v1;
string public v2;
function Test(uint256 _v1, string _v2) {
v1 = _v1;
v2 = _v2;
}
}
Here is my deployment to a --dev ...
answered Dec 22 '16 at 3:21
The Officious BokkyPooBah
32.7k9 gold badges97 silver badges171 bronze badges
17
EDIT: Solidity's author, chriseth, recommends to avoid using Solidity's call
https://github.com/ethereum/solidity/issues/2884#issuecomment-329169020
The thing is: a.call() is an ancient beast that should not be used. I would recommend using inline assembly for such tasks, since it provides the same security guarantees but does not do any invisible magic.
...
17
It means that now you need to change your code to:
uint256 _unixTimestamp;
uint256 _timeExpired;
bytes32 output = keccak256(
abi.encodePacked(msg.sender, _unixTimestamp, _timeExpired)
);
15
Functions (aka Methods) are specified by the ABI, and have a Method ID, which is the first 4 bytes of the sha3 (Keccak-256) of the method's signature.
Here's an example of invoking someFunction on contract:
contract.call(bytes4(sha3("someFunction()")))
Here is a tested function with passing a methodId as a parameter:
contract C1 {
uint public _n; // ...
15
The page "Verify Contract" ask for "Constructor Arguments ABI-encoded".
In your case the constructor has no parameters, so you can leave such field empty.
In the general case when your constrctor has parameters you can proceed as follow:
You can use ethereumjs-abi to encode/decode the parameters for transaction calls.
Let's suppose your constructor is ...
13
Contract Defintion: Formal definition in high-level code (e.g. solidity).
Compiled Contract: The contract converted to byte-code to run on the Ethereum Virtual Machine (EVM), adhering to the specification. Note the function names and input parameters are hashed during compilation. Therefore, for another account to call a function, it must first be given the ...
13
Seems like the contract address should be enough.
You're right, it would be better if the ABI could be obtained by just looking at the contract.
So why do contract writers need to also provide the ABI, in addition to the contract address?
One reason is that the function Method IDs in a contract are computed using a hash function. So it is infeasible for ...
11
You don't need the source code, just the ABI. The ABI is produced when the code is compiled, but can be, and usually is, distributed separately.
The ABI is essentially just a list of the function names in a contract and what types of arguments they take. You don't even need the whole ABI, just the parts that you want to interact with. For example, to ...
11
Mainly due to optimizations carried out when the source code is compiled it's not feasible to get the source code from the bytecode/opcode itself. Refer this question.
Compilation back to the original source code is impossible because all
variable names, type names and even function names are removed. It
might be technically possible to arrive at some ...
10
It's the job of the compiler to produce the correct EVM bytecode so that as you say the MethodID "piece of data will end up jumping to the appropriate address for that function in the bytecode of the contract".
Since the MethodID is only 4 bytes, hash collisions (between 2 different functions) are possible. The Solidity compiler gives an error in that case ...
10
Here are instructions to find contract ABI using online remix solidity compiler.
In the "Compile" tab, click on the "Details" button.
On the modal, go down to the "Interface" section. Click the copy button.
9
think of "ABI" as an "API" at a low level.
Think of it as the compiled version of an API (or as an API on the low level). As you know the contracts are stored as bytecodes in a binary format into the blockchain under a specific address. No one understands binary, so the ABI defines the structures and methods that you will use to interact with that binary ...
9
I cannot find the contract details to get the json interface anymore.
If you select the compile tab, there you will find a button called details. When the details is clicked, a pop-up window will appear. You can find the ABI at
under the metadata section, and there output you will see the ABI
(json interface).
OR
under the interface section
Click green ...
8
the specific function should be executed in EVM with related input
data rather than the whole contract code
The EVM will execute the contract code. The EVM just executes the bytecode and does not know anything about functions. Solidity, Serpent and web3.js implement the same Application Binary Interface, which is how functions and data are encoded: What ...
7
If the question is about abi params, you can take a look at these two web3.js files:
https://github.com/ethereum/web3.js/blob/master/test/coder.encodeParam.js
https://github.com/ethereum/web3.js/blob/master/test/coder.decodeParam.js
Although these functions are not a part of public web3.js interface. Mostly because they need a proper refactor.
There is ...
7
To add on to Nick Johnson's answer, function types in recent versions of solidity allow you to describe function pointers now:
http://solidity.readthedocs.io/en/latest/types.html#function-types
Function types are the types of functions. Variables of function type can be assigned from functions and function parameters of function type can be used to pass ...
7
The EVM is always 256 bits big-endian. From the Yellow Paper, Appendix H: "When interpreting 256-bit binary values as integers, the representation is big-endian."
RLP is different from the Contract ABI.
From above RLP wiki, encodings "must be represented in big endian binary form with no leading zeroes."
There are no (other) explicit rules about padding ...
7
It will be easier to understand if we make these two definitions (note: this might not be fully correct, but is enough for the following explanation):
the EVM is the machine executing the instructions, which has inputs and outputs
the state manager as the one putting data in/out of the blockchain.
Many of the interactions with the blockchain (and state ...
7
You need to add a transaction object to tell geth what account to use for the transaction:
MyContractInstance.submitUnits('10', {from: eth.accounts[0], gas:3000000});
7
Just got in touch with avsa who was kind enough to point me in the correct direction:
[{"constant":false,"inputs":[{"name":"_owner","type":"address"}],"name":"removeOwner","outputs":[],"type":"function"},{"constant":false,"inputs":[{"name":"_addr","type":"address"}],"name":"isOwner","outputs":[{"name":"","type":"bool"}],"type":"function"},{"constant":true,"...
7
Generally, no! It can be dangerous.
If you are asked to send such a transaction, you should understand what is the source code of the address you are sending to, and what function you might be invoking with the data you are sending.
Do not send arbitrary data to some arbitrary address because that is like running an arbitrary program, clicking on an ...
7
Prior to Solidity 0.5.0, both functioned the same way. The warning is part of the process of deprecating the variable-argument versions of keccak256 and other hash functions.
As of Solidity 0.5.0, sha3 has been removed. See https://github.com/ethereum/solidity/issues/3955 for details.
6
greeter and mortal are constructors, and like in other languages, only callable once, during instantiation.
6
eth's answer applies to external function calls (between contracts, or by using the external interface to call your own contract); here I'll attempt to answer for internal function calls.
Solidity currently provides no syntax for describing the type of a function pointer, so you can't take them as arguments or return values. However, functions are first-...
6
Here is how you get the abi by using your local solc compiler:
solc filename.sol --abi
You also need the bin code to deploy the contract, which you can get as follows:
solc filename.sol --bin
If you want a solc combined output (e.g. for parity), where bin is part of the abi json string, use this:
solc filename.sol --combined-json abi,bin
Only top voted, non community-wiki answers of a minimum length are eligible
