issue: https://github.com/ledgerwatch/erigon/issues/5884
this PR finishes the decoding of BeaconBlocksByRange responses.
`stream_test.go` now checks two sample ranges, of length 2 and 3
respectively (avoiding doing super long ranges to keep the files
relatively smaller).
https://beaconcha.in/slot/5000007 is the source i used to verify the
decoded data.
Following our previous discussion on erigon's discord, this PR requests
to upstream all Otterscan modifications to erigon's repo.
That decision comes after getting feedback from lots of users at events
this year, and although it may introduce some friction for development,
it will make integrators life easier by having all our modifications
available out of box, e.g., dappnode users will get our RPCs since their
official packages are built from erigon repo.
I'm submitting the source-code as-is, please let me know if you think
there is a better code organization.
The current set of modifications comprises only new RPCs. There are some
proposals for extra-stages that would add new tables, but they are still
WIP and will be submitted separately in future after more testing.
- Added listening methods for WebSocket subscriptions
- Listened for new blocks using the newHeads method to determine when to
look for a transaction
- Added new util methods and tests for them
- Simplified communication to the user upon initiating the devnet tool
this pr has two things in it
1. changed filter logs to use a map for the topics. this will speed up
queries with many topics in them. I still don't have a use case for this
though. i put is as a method of Logs, since that made sense to me, happy
to move it back out though.
2. allows json-rpc over http get request. since firefox is a great json
viewer (can search through, collapse large results) i often use it to
debug. it is also useful for sharing data with those who are less
familiar with command line / programming.
example get request:
http://rpcdaemon/?method=eth_getLogs¶ms=[{"fromBlock":"0xf2316b","toBlock":"0xf2316b"}]
it is based on the old jsonrpc http specification
https://www.jsonrpc.org/historical/json-rpc-over-http.html#encoded-parameters
except we also accept not base64 encoded params. since every eth rpc
request has a [], it will immediately fail validation for base64 and
attempt to use the parameters as a they are. otherwise it will attempt
to parse the rest of the payload as base64 and use that.
Co-authored-by: a <a@a.a>
Co-authored-by: gfx <86091021+gfxlabs@users.noreply.github.com>
- Added new requests for sending raw transactions
- Made provisions for other types of transactions generated, including
contracts
- Modified the models and services to accommodate general values
https://github.com/ledgerwatch/erigon/issues/5884 has more context on
this issue. we are trying to understand the encoding of the responses.
from the Ethereum R&D discord, AgeManning said that the prefix is
supposed to be a varint representing the length of the payload:
https://developers.google.com/protocol-buffers/docs/encoding#varints.
that works for the `&cltypes.MetadataV1{}` type, but not for
`&cltypes.MetadataV2{}` or `&cltypes.LightClientFinalityUpdate{}`.
