6

There is a nice article about writing upgradable Solidity code article about writing upgradable Solidity code

The question is however (ref the article) if ITokenLedger is intentionally "contract" and not "interface"? Can ITokenLedger be "interface" and how this will affect the implementation of the calling "contract"?

What are the recommended methods of calling "contract" within another "contract" provided caller is only aware of the callee's ABI and address, with respect to gas consumption?

While this is most likely an noob question I appreciate your patience and thank you in advance.

6

The recommended method would be employing abstract contract (or interface) definition in solidity code (see Service.sol) and the address of the deployed contract implementing it.

Example

Deployed Service.sol:

pragma solidity ^0.4.11;

contract Service{

  function isAlive() public constant returns(bool alive) {
    // do something
    return true;
  }
}

Let's assume the deployed contract is deployed at 0x123... (see serviceAddress below).

Now we want to describe a contract that will use it for something. We'll describe the abstract contract only, so the client knows how to communicate. Then we'll pass in the address so it knows what to communicate with.

Client.sol

pragma solidity ^0.4.11;

// describe the interface

contract Service{
  function isAlive() constant returns(bool alive) {} // empty because we're not concerned with internal details
}

contract Client {
  Service _s; // "Service" is a Type and the compiler can "see" it because this is one file. 

  function Client(address serviceAddress) {
    _s = Service(serviceAddress); // _s will be the "Service" located at serviceAddress
  }

  function Ping() public constant returns(bool response) {
    return _s.isAlive(); // message/response to Service is intuitive
  }
}

Calling deployed contract by ABI and address is similar to a reflection call (expensive) with the limitation that the only output from the call is a boolean return value designating success (true) or an exception (false).

  • Thank you for prompt response! Would you be able to validate the following two statements: 1. Both, interface and abstract contract will generate ABI which is exactly the same and does exactly correspond to the ABI of the contract implementing either or both. 2. Compiler does not produce byte-code neither for interface (my question) nor for abstract contract (your example). This makes it impossible to deploy and hence does not employ blockchain as a "publication/distribution mechanism". It is only possible to deploy bytecode generated from a contract or a library. – Alexander Yarushin Aug 20 '17 at 9:58
  • If the above two statements validate true then: Q1. The only way of distributing interface or abstract contract and not compromise type safety is to share their solidity code? Q1.1 Or is there a way to generate solidity code for these off the ABI? (Aka WCF client generation off WSDL) – Alexander Yarushin Aug 20 '17 at 9:59
  • Is ABI and address of the deployed contract enough: A. to call the contract from another contract. B. to make a transaction from an external account. Q2 What are the best practices for use case (A) and (B) provided one only knows the ABI and the address. Q2.1 Is it correct that in case of contract invokation by only ABI + address the type safety is not employed? (Aka invokation via reflection) – Alexander Yarushin Aug 20 '17 at 10:00
  • I just found a relevant question with good answers: ethereum.stackexchange.com/questions/9733/…. It discusses recommended calling method which is the same as the one @Rob_Hitchens and the article by Elena_Dimitrova from Coloni in the original question describes. – Alexander Yarushin Aug 20 '17 at 13:18
  • More on the subject: solidity.readthedocs.io/en/latest/… – Alexander Yarushin Aug 20 '17 at 13:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.