How about allowing mapping each contract to a table?

[bernardpeh]

great work @xiaoyao1991

if we come up with a standard interface and make each smart contract adhere to certain standards, we could potentially turn each contract into a table.

contract Users {
  struct User {
    uint public id;
    address public user; 
    bytes public email;
  }

  mapping (uint => User) users;

  function addUser(address _user, bytes _email) public returns (bool success) {
    ...  
  }
  ...
}

contract UserMetas {
  struct Meta {
        byte public streetAddress;
        bool public accountEnabled;
        uint public age;
    }
  // where uint is the foreign key
  mapping (uint => Meta) metas;
}

to get user 1 details, we could

select result from UserMetas, User where User.id = UserMetas.id and User.id = 1;

We are turning the blockchain like a normal db. I think there might be use case for this.

[xiaoyao1991]

Thank you @bernardpeh for making this suggestion. The idea of "one contract one table" is interesting. And you are right about having a standard interface. Presto-ethereum now tracks ERC20 tokens by intercepting the transfer event log. The event is part of the ERC20 standard, so every legit token should emit such events when a transfer happens. As you see, presto-ethereum is not really looking into the state storage of the contracts, but only looking at event logs. it's not easy to have presto directly ask for state storage.

At this point, I think what you can do if you want to query a contract as a table, is to try to emit certain event logs in similar ways of ERC20 transfer event.

What do you think?

[bernardpeh]

@xiaoyao1991 user event log technique is good. maybe an event naming convention would allow us to achieve this, like colxxx, so presto sees event name starting with "col", it will strip it off and use the var after the "_" as column name . I will play around with your code. presto-ethereum is itself a cool idea.

[xiaoyao1991]

@bernardpeh Thanks! Intercepting event with naming convention like col_xxx is ideal, but it's not easy. The reason is that the event logs are SHA3 hash of the event signature. There's no way to check if a given event is of a certain format. Only point-to-point matching can be done.

With that said, I could think of 2 approaches. We could either have only one general event, like col_general(string col_name, ...), this way we can intercept the event logs the same way we do with erc20 transfer. Disadvantages of this approach is also obvious, there can maximum 4 fields that an event can carry, the expressiveness is quite limited.

We could also have presto-ethereum read some config files with smart contract source code (or its abi in some format) so that it knows the metadata, what are the events to expect. I think this might be a better way to go. Anyway you'll need to change the part of the code that add new tables to presto.

Let me know @bernardpeh about your progress on this. I find your ideas really interesting, and we can definitely work together.

[bernardpeh]

yeah this feature might be too big to discuss here. I think we will get better insights if we take this offline.