Signatures aggregation service

[rimrakhimov]

Currently there are several solutions that implement Ethereum signature databases and provides an API to search for the functions and events by their selectors (https://sig.eth.samczsun.com/, https://www.4byte.directory/). Those databases may contain very similar but not identical information. We would like to implement a service that a) makes a call to those databases to search for corresponding methods, aggregates responses and return aggregated data to the caller; b) submits new ABIs to those databases.

• [x] Process functions
• [ ] Process events https://github.com/blockscout/blockscout-rs/issues/211
• [x] Update smart-contract verifier to send ABIs to sig-provider service https://github.com/blockscout/blockscout-rs/issues/212

[rimrakhimov]

Endpoint (a)

Endpoint (a) could be called from the main blockscout instance when it needs to decode a transaction of unverified contract.

Currently, internal per chain database is used for that purpose, but using 3-rd party signature databases could allow us to increase the amount of data available and remove per chain restriction without implementing shared database ourselves.

[rimrakhimov]

Endpoint (b)

Regarding endpoint (b) we have considered 3 possible options what service should import a new ABIs into it:

Option 1

The aggregation service is responsible only for importing ABIs into Ethereum Signature Databases. Data into signatures-aggregator is submitted by Blockscout instance after smart-contract-verifier returns verification result. No changes into smart-contract-verifier are required, but Blockscout instance should know about

The main problems here are increased coupling between services and the way our team is structured. As Blockscout is only a proxy between smart-contract-verifier and signatures-aggregator, if some additional data is required for signatures-aggregator (e.g. if metadata information would become important), Blockscout will have to proxy that data from smart-contract-verifier response and, thus, update of all three services APIs will be required. Considering that Blockscout instance is developed by Elixir team, while signatures-aggregator and smart-contract-verifier are developed in Rust, the issue would cross the team border which further makes the things even worse.

[rimrakhimov]

Endpoint (b) (cont)

Option 2

The aggregation service is responsible only for importing ABIs into Ethereum Signature Databases. But data into signatures-aggregator is submitted by smart-contract-verifier directly. The Blockscout instance does not know anything about signatures-aggregator and requires no changes at all.

That approach removes the proxy logic and allows us to encapsulate any API changes inside the smart-contract-verifier - signatures-aggregator interaction. In case of any changes only those two services will have to be updated.

The approach has a disadvantage, though, that smart-contract-verifier service lose its "puriness" - the fact that its all functionality is to accept requests from the clients, compile and verify contracts, and return responses back without any additional interactions.

[rimrakhimov]

Endpoint (b) (cont)

Option 3

In the third option, we return back to the proxy approach but instead of using a Blockscout instance as a proxy, we implement a new microservice named smart-contract-verifier-proxy.

That service allows smart-contract-verifier not to to be changed and to be left "pure", while encapsulating API changes (if any) inside the Rust team only. Additionally, that way we may have a better scaling granularity, as (most probably) one smart-contract-verifier-proxy will serve responses from several smart-contract-verifier services.

However, though changes will be implemented inside the Rust team only, the approach still requires three different services to be changed in case of any API update. Besides that, if some user will decide to eliminate proxy service (e.g. they won't want to send ABIs to 3-rd party databases) it may be difficult to remove proxy and configure Blockscout to call smart-contract-verifier directly.

[sevenzing]

I suggest considering a few other short names for this service:

• eth-sig-proxy
• sig-documenter
• sig-storage
• sig-provider

[rimrakhimov]

@sevenzing Thank you! I personally like sig-provider variant, but I suggest to create a poll regarding the naming when the service functionality would be finalized

[vbaranov]

In regards, Endpoint (b) Option 2

The approach has a disadvantage, though, that smart-contract-verifier service lose its "puriness" - the fact that its all functionality is to accept requests from the clients, compile and verify contracts, and return responses back without any additional interactions.

We could make that integration with sig databases optional, and the base smart-contract-verifier service will still be "pure".

Anyways, Endpoint (b) Option 2/Option 3 look more preferable than Option 1 since Option 1 requires efforts from 2 teams (Elixir/Rust). And both Option 2/Option 3 look viable to me.

[rimrakhimov]

We could make that integration with sig databases optional, and the base smart-contract-verifier service will still be "pure".

Yes, probably, in case of Option 2, we may implement that via some kind of middleware implementation, if we add Middleware trait as described in #132

[leviska]

So overview of current databases:

1. https://sig.eth.samczsun.com/ We need only abi
2. https://www.4byte.directory/docs/ We need only abi too

So I suggest we can make a minimalist api, which will accept contract address (for future proofing) and abi. Not sure what we might need in the future, so I think this will be enough for now