You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The archive node support as implemented in #281 is sub-optimal in that it uses a dedicated web3 gw instance to handle queries that hit up the archival oasis-node instance. This is because oasis-node's grpc interface is not guaranteed to be stable and in fact has changed in a binary incompatible way.
As it is essentially impossible to import multiple versions of go packages in a useful manner (No, replace in go.mod does not work), the decision was made to use an archival web3 gateway instance that the non-archival web3 gateway instance will query to service 5 calls.
While there is (untested) support for having web3 gateway instances share the backing database, in an ideal world, a single web3 gateway instance will be able to handle both current and archival queries.
The text was updated successfully, but these errors were encountered:
nb: Filing this here, though this probably needs changes in https://github.com/oasisprotocol/oasis-sdk
The archive node support as implemented in #281 is sub-optimal in that it uses a dedicated web3 gw instance to handle queries that hit up the archival oasis-node instance. This is because oasis-node's grpc interface is not guaranteed to be stable and in fact has changed in a binary incompatible way.
As it is essentially impossible to import multiple versions of go packages in a useful manner (No, replace in go.mod does not work), the decision was made to use an archival web3 gateway instance that the non-archival web3 gateway instance will query to service 5 calls.
While there is (untested) support for having web3 gateway instances share the backing database, in an ideal world, a single web3 gateway instance will be able to handle both current and archival queries.
The text was updated successfully, but these errors were encountered: