3

I am trying to implement a Java interface to be able to call FA1.2 smart contract entrypoints programmatically. This is what I've got now:

public interface FA12
{
   public JSONObject transfer(String from, String to, Integer value) throws Exception;
   public JSONObject approve(String spender, Integer value) throws Exception;
   public JSONObject getAllowance(String owner, String spender) throws Exception;
   public JSONObject getBalance(String owner) throws Exception;
   public JSONObject getTotalSupply(Integer total) throws Exception;
}

But I was told that these get operations should not return a value. Instead, I should use callbacks to get the results: Apparently I should call a VIEW entrypoint and supply to the view an address and a callback contract. That's not something trivial, even for an experienced developer as I am. What callback contract address should I use? One that I have deployed my own? All contracts have its own callback contract address?

I am having some difficulty while trying to understand the correct way to do it.

My goal here is just calling getBalance() to check how many tokens an address has in a mainnet deployed contract.

Please, any help will be appreciated. Thanks in advance.

2

You are correct. There is not a way to get the value directly. You would have to originate a contract like this. Let's call it getnat.tz. We will use it to create an error message after a dry run call.

parameter (nat);
storage unit;
code { CAR; FAILWITH };

Now we can call it from the client.

tezos-client transfer 0 from alice to token \
             --entrypoint 'getBalance' \ 
             --arg 'Pair "<token-owner-address>" "<getnat-address>"' \
             --dry-run

This will produce an error message with the value. You will have to parse it. If you add the -l flag you can see the RPC routes that tezos-client calls to recreate it in your application.

  • Won't this cause a space issue in Tezos blockchain sooner or later? I mean, each call to a contract entrypoint will build a new contract to receive an answer? Seems odd to me. – Luiz Milfont Jun 16 '20 at 17:13
  • 1
    It is possible with one contract but it requires a tool that generates some lambda code for you. Take a look at this github.com/tqtezos/lorentz-contract-view – MCH Jun 16 '20 at 17:25
  • The --dry-run parameter avoid actual contract deployment to the blockchain, right? Is there a parallel using an RPC call? – Luiz Milfont Jun 16 '20 at 23:10
  • 1
    Right. We actually only need on contract deployed for everyone to use. It is detailed in that github repo. Then the dry run calls to it are free. Yes, the tezos-client interacts with the blockchain via the RPC. Use the -l flag to see what is being called and you can imitate it. – MCH Jun 17 '20 at 1:12
-3

After talking to many active Tezos community members, I have finally found a solution:

public interface FA12
{
   public void transfer(String from, String to, Integer value) throws Exception;
   public void approve(String spender, Integer value) throws Exception;
}

Which means that I only need to implement the contract calls that actually do an action (like transfer and approve). All other entrypoints that require a "VIEW" type, like getBalance, getAllowance or getTotalSupply are entrypoints to be called between contracts. In my case I can check all information I need by parsing the contract STORAGE, so I can avoid the hurdles associated with dummy contracts created to serve as a callback for responses.

  • If you know the storage of a particular FA1.2 contract, then you can try to read it, but the standard does not mention any requirement of having storage of a particular shape so you cannot trust the storage for any random FA1.2. The reason is the author of an FA1.2 contract may decide that the total supply increases/decreases over time or change for some other condition. A contract does not update itself but getBalance should calculate the value at the time it is called. – MCH Jun 16 '20 at 21:37
  • Hmmm. I see. That sends me a step backwards... So getBalance implementation seems to be needed. And so does that trickery with a dummy callback contract... – Luiz Milfont Jun 16 '20 at 22:50
  • 1
    In the short term that is the solution. In the long term you could talk to community members and core developers to gather interest in changing Tezos so that this work around is not necessary. – MCH Jun 17 '20 at 1:13

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.