ethpandaops / dora Goto Github PK

View Code? Open in Web Editor NEW

70.0 5.0 20.0 3.45 MB

Dora the Explorer is a lightweight slot explorer for the ethereum beaconchain

Home Page: https://beaconlight.ephemery.dev/

License: GNU General Public License v3.0

Go 67.78% CSS 1.29% JavaScript 1.73% HTML 28.83% Makefile 0.06% Dockerfile 0.04% Shell 0.26%

ethereum eth2-beacon-chain explorer eth2

dora's Introduction

Dora the Beaconchain Explorer

What is this?

This is a lightweight beaconchain explorer.

A Beaconchain explorer is a tool that allows users to view and interact with the data on the Ethereum Beacon Chain. It is similar to a blockchain explorer, which allows users to view data on a blockchain such as the current state of transactions and blocks - but focussed on exploring the beaconchain.

This "lightweight" explorer loads most of the information directly from an underlying standard beacon node api, which makes it a lot easier and cheaper to run (no 3rd party proprietary database like bigtables required).

Testnet instances

Holešky Testnet:

Sepolia Testnet:

https://dora.sepolia.ethpandaops.io/

Ephemery Testnet:

https://beaconlight.ephemery.dev/

Setup & Configuration

Read through the wiki for setup & configuration instructions.

Dependencies

The explorer has no mandatory external dependencies. It can even run completely in memory only.
However, for best performance I recommend using a PostgreSQL database.

Development Setup

The repository contains a script that simplifies spinning up a development environment for the explorer.

Follow these steps to spin up a full ethereum testnet with the locally build dora instance:

Ensure docker & (kurtosis)[https://docs.kurtosis.com/install] are installed on your machine.
Clone the repository
Run make devnet-run

The make devnet-run command spins up a kurtosis testnet with multiple client pairs. To stop the testnet after development work, run make devnet-clean

Thanks To

This explorer is heavily based on the code from gobitfly/eth2-beaconchain-explorer.

License

dora's People

Contributors

Stargazers

Watchers

dora's Issues

Thank you for this great project

Dear @ethpandaops

We used Dora for our project: Canxium, it's really awesome, could you please give us your wallet, we'd like to send you some CAU coin as a donation (metamask wallet is fine)

Best Regards.
Neo Krypt.

display genesis

the dora explorer does a good job displaying the consensus slot with the execution payload

https://dora-holesky.pk910.de/slot/2

however, it does not do it for genesis. the structure should be the same though?

https://dora-holesky.pk910.de/slot/0

SQL Error when updating validator names in db

time="2024-01-06T22:29:59Z" level=error msg="error while deleting validator names from db" error="expected 10000 arguments, got 20000" module=validator_names

Orphaned block detection not working properly

I've noticed some issues with the orphaned block detection:
https://beaconlight-devnet.pk910.de/epoch/7346
https://beaconlight-devnet.pk910.de/epoch/7737

Looks like the reorg detection marks too many blocks as orphaned..
Needs further debugging

Bug: Attestation cache for activity aggregation is too small to give reasonable validator status

Due to the fix of #47, dora usually keeps only 1-2 epochs in memory before the finalization routine cleans them up.
As the most recent epoch is most likely incomplete, it leaves dora with only 1 usable epoch to generate the validator activity aggregation for.
This is not enough to give a reasonable online/offline status for validators.

To fix this, dora should keep validator activity aggregations for finalized epochs in memory for 2-3 more epochs.
This should be enough for a clear online/offline status detection.

The cache does not need to be persisted.
If dora gets restarted, the activity overview will be inaccurate for a few epochs, but that's fine.

Feature: Track slashings

Feature Request:
Add a list of attester / proposer slashings / track slashings in db

`killSwitch.DisableSSZRequests` doesn't work anymore

The functionality behind DisableSSZRequests has accidentally been removed when re-implementing the indexer (#83)

This should be added again as the killswitch is needed for networks with special SSZ features that are not supported by dora.

Improve canonical head selection

The explorer sees the forked off chain from nimbus clients as canonical chain here.
This is a non-persistent issue, which already resolved itself a block after.
The explorer selects the canonical chain head on the fly based on the heads from all connected clients.
It looks like the nimbus head was selected here because it has the highest slot number. This logic should be improved.

Wait for go-eth2-client Issue #35 and replace workaround code

The attestantio/go-eth2-client implementation currently does not return the metadata fields supplied via various endpoints.
But the explorer needs the dependent_root field from /eth/v1/validator/duties/proposer/{epoch} call.
So there is currently a workaround code that does the getProposerDuties on its own.

This workaround code should be removed once the upstream library has support for these metadata fields.

Wait for attestantio/go-eth2-client#35
Remove workaround code here

High memory usage

The explorer currently consumes quite much memory for operation.
Biggest memory consumptions:

Loading & parsing of validator sets [~1.5GB per request on holesky]
Unfinalized Block Cache [~1GB for >500 unfinalized epochs]
Page Model Cache [200MB as per config]

Especially the first point should be improved.
The explorer currently does up to 2 validator set requests in parallel, so it's consuming up to 3GB just for parsing some giant json

Bug: Dora doesn't connect to clients that are stuck at genesis

time="2024-02-02T12:45:44Z" level=info msg="http server listening on 0.0.0.0:8080"
time="2024-02-02T12:45:44Z" level=info msg="received block 0:0 [0x71ca733aff61e91d304fe23b869010fd267a4a3931a736c6729a7657ca670507] warmup, head" client=cl-1-lighthouse-geth module=indexer
time="2024-02-02T12:45:44Z" level=warning msg="indexer client error: could not find parent header 0x0000000000000000000000000000000000000000000000000000000000000000, retrying in 10 sec..." client=cl-1-lighthouse-geth module=indexer
time="2024-02-02T12:45:54Z" level=warning msg="indexer client error: could not find parent header 0x0000000000000000000000000000000000000000000000000000000000000000, retrying in 10 sec..." client=cl-1-lighthouse-geth module=indexer
time="2024-02-02T12:46:04Z" level=warning msg="indexer client error: could not find parent header 0x0000000000000000000000000000000000000000000000000000000000000000, retrying in 10 sec..." client=cl-1-lighthouse-geth module=indexer

the client is stuck with the genesis block:

~# curl http://127.0.0.1:32832/eth/v1/beacon/headers
{"execution_optimistic":false,"finalized":false,"data":[{"root":"0x71ca733aff61e91d304fe23b869010fd267a4a3931a736c6729a7657ca670507","canonical":true,"header":{"message":{"slot":"0","proposer_index":"0","parent_root":"0x0000000000000000000000000000000000000000000000000000000000000000","state_root":"0xfe842cf4d68b07159db26cfca3ebfe14b030d48438a6e5e9745eea78f6b8153f","body_root":"0x74b4bb048d39c75f175fbb2311062eb9867d79b712907f39544fcaf2d7e1b433"},"signature":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"}}]}

Handle large chain reorgs with >32 slots

This is not implemented yet and will cause some index inconsistency when it happens.
However, I guess such big reorgs normally shouldn't happen ever.

Client fork grouping does not work for clients that are stuck before the finalization checkpoint

The grouping for the clients fork page does not work properly for clients that are stuck before the finalization checkpoint:

This is happening because dora can't check block relationships for blocks that are older than the finalization checkpoint.
These blocks are no longer in cache, so dora can't iterate their parent tree to group matching fork chains.

#111 is a temporary workaround to group clients that are stuck at the exact same block root.

Add option to disable proposer duty polling after epoch

Background

Whisk SSLE (Single Secret Leader Election) is a new Ethereum protocol feature being tested now. (ref: https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763)

The point of the feature is to identity of the next proposer private until its block is published. This means:

proposer duties cannot be known in advance
if there is a missed slot it will never be known how missed the slot

@parithosh has deployed a testnet for whisk https://github.com/ethpandaops/whisk-testnets/ with this explorer. BTW great work on the explorer, love it so far! ❤️

However the explorer stalls indexing at the Whisk fork epoch since it cannot poll duties. More precisely, the beacon node returns an error to calls to eth/v1/validator/duties/proposer/ since it cannot serve that data.

INFO[0008] synchronizing epoch 0                         module=synchronizer
WARN[0008] could not lazy load proposer duties for epoch 1501: error retrieving proposer duties: url: http://localhost:5052/eth/v1/validator/duties/proposer/1501, error-response: {"code":500,"message":"UNHANDLED_ERROR: BeaconStateError(NoProposerShuffleAfterWhisk)","stacktraces":[]}  client=default module=indexer
WARN[0008] could not find proposer duties for epoch 1501  client=default module=indexer
WARN[0008] could not lazy load proposer duties for epoch 1503: error retrieving proposer duties: url: http://localhost:5052/eth/v1/validator/duties/proposer/1503, error-response: {"code":500,"message":"UNHANDLED_ERROR: BeaconStateError(NoProposerShuffleAfterWhisk)","stacktraces":[]}  client=default module=indexer
WARN[0008] could not find proposer duties for epoch 1503  client=default module=indexer
WARN[0008] could not lazy load proposer duties for epoch 1502: error retrieving proposer duties: url: http://localhost:5052/eth/v1/validator/duties/proposer/1502, error-response: {"code":500,"message":"UNHANDLED_ERROR: BeaconStateError(NoProposerShuffleAfterWhisk)","stacktraces":[]}  client=default module=indexer
WARN[0008] could not find proposer duties for epoch 1502  client=default module=indexer
INFO[0010] received block 1503:48117 [0x6a322ff15c787ce63c92a0c062f4ce462263cb8d58737e7829bc25d40ca88473] stream  client=default module=indexer
INFO[0015] index page called

It would be great to have this explorer be compatible with Whisk for ease of debugging on devnets and to start iterating on how explorers would deal with post-whisk world with proposer privacy.

Please let me know what ideas you have to deal with case, I will suggest some ideas below

Bug: Dora keeps getting stuck in rare situations

Dora keeps getting stuck in rare situations.

This seems to be related to bad client connections, which makes dora running into a deadlock.
The dora core logic (including client pool & block cache) should be reworked to make such deadlocks impossible
(ie. use channels and contexts instead of locking)

Feature: Allow sorting clients on fork page by block distance

Wait for go-eth2-client PR #75 and disable initial connection check

The explorer currently can't use clients that do not explicitly follow the specs for some static api calls.
This is due to the initial connection checks implemented in attestantio/go-eth2-client.

I think these checks should be disabled for the explorer, as the explorer does its own error handling for the api calls it uses.
Especially for early testnets there might be clients that do not follow the specs that closely.
However, they should still be used as much as the explorer can use them.

Wait for attestantio/go-eth2-client#75
Disable initial connection check here

~~This issue currently prevents the explorer from using prysm nodes due to this prysm bug:~~
~~prysmaticlabs/prysm#12949~~
Edit: Prysm issue has been resolved

Scheduled blocks missing on slot overview

Feature: show transactions in block details

Feature request:
The explorer should be able to show eth transaction details on the block details page.

Current status:
The explorer only displays the transaction count, but no further transaction details.
Technically the signed transactions are available for post-bellatrix blocks without adding further complexity by calling a EL RPC.
However, they're not yet decoded or visualized.

I think it'd be great to get some basic details (hash, from/to addr, amount, & call data) displayed for each transaction in the block details.
Further transaction details like receipt information, events, internal transactions or tx traces should not be included for the first implementation.
Showing that stuff would need some EL RPC interaction, which introduces additional complexity that might not be worth adding.

Decoding the transactions should be easy: example

I think that's a good first issue for anyone who wants to join development for this explorer :)
Anyone who contributed to beaconcha.in before will probably feel familiar with the structure of this lightweight explorer ;)

Block graph breaks layout with many forks

Doesn't look good ;)
The graph column should be properly sized, so the graph is fully visible

Error when going to older pages

I was looking at the devnet-1 explorer and it was not able to get past page 6, with this URL
https://dora.pectra-devnet-1.ethpandaops.io/slots?s=1855&c=50

This had the following error:



URL: /slots?s=1855&c=50
Time: 2024-07-23 18:00:52.262374727 +0000 UTC m=+908.117313918
Version: git-fbf266b

Error:
page call 125 panic: reflect: reflect.Value.Set using unaddressable value

Stack Trace:
goroutine 11807 [running]:
runtime/debug.Stack()
	/opt/hostedtoolcache/go/1.21.12/x64/src/runtime/debug/stack.go:24 +0x5e
github.com/ethpandaops/dora/services.(*FrontendCacheService).processPageCall.func1.1()
	/home/runner/work/dora/dora/services/frontendcache.go:122 +0xd4
panic({0x15a3440?, 0xc00b1a2c90?})
	/opt/hostedtoolcache/go/1.21.12/x64/src/runtime/panic.go:914 +0x21f
reflect.flag.mustBeAssignableSlow(0xc00b0a3960?)
	/opt/hostedtoolcache/go/1.21.12/x64/src/reflect/value.go:272 +0x74
reflect.flag.mustBeAssignable(...)
	/opt/hostedtoolcache/go/1.21.12/x64/src/reflect/value.go:259
reflect.Value.Set({0x1759300?, 0x0?, 0x41b4a8?}, {0x1759300?, 0xc00b0a3960?, 0xc0092175e8?})
	/opt/hostedtoolcache/go/1.21.12/x64/src/reflect/value.go:2254 +0x65
github.com/pk910/dynamic-ssz.(*DynSsz).unmarshalType(0xc0092176d8, {0x1e3f0c8, 0x1759300}, {0x1759300?, 0x0?, 0x16a1e60?}, {0xc0002c3600, 0xcc5, 0xd80}, {0xc009217630, ...}, ...)
	/home/runner/go/pkg/mod/github.com/pk910/[email protected]/unmarshal.go:47 +0x198
github.com/pk910/dynamic-ssz.(*DynSsz).UnmarshalSSZ(0x1844451?, {0x1759300?, 0x0?}, {0xc0002c3600?, 0xcc5, 0x2c?})
	/home/runner/go/pkg/mod/github.com/pk910/[email protected]/dynssz.go:106 +0xe6
github.com/ethpandaops/dora/indexer.UnmarshalVersionedSignedBeaconBlockSSZ(0x6, {0xc0002c3600, 0xcc5, 0xd80})
	/home/runner/work/dora/dora/indexer/ssz_helper.go:104 +0x3a6
github.com/ethpandaops/dora/indexer.(*CacheBlock).GetBlockBody(0xc0076b4fc0)
	/home/runner/work/dora/dora/indexer/cache_block.go:155 +0x135
github.com/ethpandaops/dora/indexer.buildDbBlock(0xc0076b4fc0, 0xc00a6bd970)
	/home/runner/work/dora/dora/indexer/write_db.go:176 +0x32
github.com/ethpandaops/dora/indexer.(*Indexer).BuildLiveBlock(0x28feea0?, 0xc0076b4fc0)
	/home/runner/work/dora/dora/indexer/indexer.go:680 +0x17c
github.com/ethpandaops/dora/services.(*ChainService).GetDbBlocksForSlots(0xc000158fc0, 0x73f, 0x32, 0x1, 0x1)
	/home/runner/work/dora/dora/services/chainservice_blocks.go:347 +0xa6c
github.com/ethpandaops/dora/handlers.buildSlotsPageData(0x73f, 0x32)
	/home/runner/work/dora/dora/handlers/slots.go:124 +0x327
github.com/ethpandaops/dora/handlers.getSlotsPageData.func1(0xc00b0d5b80)
	/home/runner/work/dora/dora/handlers/slots.go:57 +0x25
github.com/ethpandaops/dora/services.(*FrontendCacheService).processPageCall.func1(0x1c608e8?)
	/home/runner/work/dora/dora/services/frontendcache.go:137 +0x1de
created by github.com/ethpandaops/dora/services.(*FrontendCacheService).processPageCall in goroutine 10126
	/home/runner/work/dora/dora/services/frontendcache.go:116 +0x2b4

Now it says 503 Service Temporarily Unavailable, I hope I didn't break it!

Support basic EIP-7702 decoding

EIP-7702 transactions do not show up in the transaction list for execution payloads

EIP link

Bug: Finalized/Justified epoch is "delayed" by one.

The explorer currently grabs the finalization status too early during epoch transition and therefore shows finalized epochs an epoch later than it should.

Bug: slot view not loading

I started this kurtosis configuration:

participants:
    - el_type: geth
      el_image: "192.168.45.152:80/dh/ethpandaops/geth:lightclient-prague-devnet-0"
      el_image: "ethpandaops/geth:lightclient-prague-devnet-0"
      cl_type: grandine
      cl_image: ethpandaops/grandine:feature-electra
      count: 3
network_params:
  electra_fork_epoch: 1
additional_services: [dora]
snooper_enabled: true

Slots are being proposed but when I try to open the page for a slot I get "Internal server error".

Docker logs indicate:

time="2024-05-13T11:37:56Z" level=error msg="error executing template" error="html/template:slot.html:212:24: no such template \"block_consolidation\"" error type="*template.Error" file=index.go function=Slot info= route=/slot/30

Bug: panic in type ahead search handler

Noticed a panic in the holesky dora logs:

[negroni] PANIC: runtime error: cannot convert slice with length 0 to array or pointer to array with length 32
goroutine 223955 [running]:
github.com/urfave/negroni.(*Recovery).ServeHTTP.func1()
	/go/pkg/mod/github.com/urfave/[email protected]/recovery.go:159 +0xc7
panic({0x1326780, 0xc03a70c570})
	/usr/local/go/src/runtime/panic.go:884 +0x213
github.com/pk910/dora-the-explorer/handlers.SearchAhead({0x7f14ffc0d7e0, 0xc02118a028}, 0xc00dfb8700)
	/src/handlers/search.go:308 +0x210f
net/http.HandlerFunc.ServeHTTP(0xc00dfb8600?, {0x7f14ffc0d7e0?, 0xc02118a028?}, 0x446d3c?)
	/usr/local/go/src/net/http/server.go:2122 +0x2f
github.com/gorilla/mux.(*Router).ServeHTTP(0xc000000000, {0x7f14ffc0d7e0, 0xc02118a028}, 0xc00dfb8500)
	/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:210 +0x1cf
github.com/urfave/negroni.Wrap.func1({0x7f14ffc0d7e0, 0xc02118a028}, 0x12a5d60?, 0xc01fc0c120)
	/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:46 +0x4b
github.com/urfave/negroni.HandlerFunc.ServeHTTP(0x41e510?, {0x7f14ffc0d7e0?, 0xc02118a028?}, 0xc04dc8b900?, 0xc04dc8b978?)
	/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:29 +0x33
github.com/urfave/negroni.middleware.ServeHTTP({{0x1817c80?, 0xc0004e6378?}, 0xc0004e63f0?}, {0x7f14ffc0d7e0, 0xc02118a028}, 0x12a5d60?)
	/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38 +0xb6
github.com/urfave/negroni.(*Recovery).ServeHTTP(0x8?, {0x7f14ffc0d7e0?, 0xc02118a028?}, 0x0?, 0xc04dc8ba50?)
	/go/pkg/mod/github.com/urfave/[email protected]/recovery.go:193 +0x86
github.com/urfave/negroni.middleware.ServeHTTP({{0x1815e60?, 0xc0001f6960?}, 0xc0004e63d8?}, {0x7f14ffc0d7e0, 0xc02118a028}, 0x0?)
	/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38 +0xb6
github.com/urfave/negroni.(*Negroni).ServeHTTP(0xc0001f3aa0, {0x1824c40?, 0xc020b340e0}, 0x46e7ce?)
	/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:96 +0x125
net/http.serverHandler.ServeHTTP({0xc020cfc660?}, {0x1824c40, 0xc020b340e0}, 0xc00dfb8500)
	/usr/local/go/src/net/http/server.go:2936 +0x316
net/http.(*conn).serve(0xc038e27dd0, {0x1825568, 0xc0001f3d70})
	/usr/local/go/src/net/http/server.go:1995 +0x612
created by net/http.(*Server).Serve
	/usr/local/go/src/net/http/server.go:3089 +0x5ed

Fork detection takes too long to keep up with the chain during long unfinality

The new fork detection takes too long when the network has large unfinality time.
This leads to dora "lagging behind" the chain head with it's fork & canonical chain computation:

(fork & canonical chain computation is 3 blocks behind)

pprof also shows subroutines being stuck in the fork detection code:

2 @ 0x443b2e 0x4569a5 0x456974 0x477b05 0x48725d 0x1010b95 0x1010b69 0xfffd91 0xffeed7 0xffe3b1 0xffdf85 0xffd4aa 0x47b9e1
#	0x477b04	sync.runtime_SemacquireMutex+0x24						/opt/hostedtoolcache/go/1.22.6/x64/src/runtime/sema.go:77
#	0x48725c	sync.(*Mutex).lockSlow+0x15c							/opt/hostedtoolcache/go/1.22.6/x64/src/sync/mutex.go:171
#	0x1010b94	sync.(*Mutex).Lock+0x74								/opt/hostedtoolcache/go/1.22.6/x64/src/sync/mutex.go:90
#	0x1010b68	github.com/ethpandaops/dora/indexer/beacon.(*forkCache).processBlock+0x48	/home/runner/work/dora/dora/indexer/beacon/forkcache.go:305
#	0xfffd90	github.com/ethpandaops/dora/indexer/beacon.(*Client).processBlock+0x3b0		/home/runner/work/dora/dora/indexer/beacon/client.go:367
#	0xffeed6	github.com/ethpandaops/dora/indexer/beacon.(*Client).processStreamBlock+0x36	/home/runner/work/dora/dora/indexer/beacon/client.go:266
#	0xffe3b0	github.com/ethpandaops/dora/indexer/beacon.(*Client).processHeadEvent+0xf0	/home/runner/work/dora/dora/indexer/beacon/client.go:180
#	0xffdf84	github.com/ethpandaops/dora/indexer/beacon.(*Client).runClientLoop+0x824	/home/runner/work/dora/dora/indexer/beacon/client.go:153
#	0xffd4a9	github.com/ethpandaops/dora/indexer/beacon.(*Client).startClientLoop+0x69	/home/runner/work/dora/dora/indexer/beacon/client.go:99

1 @ 0x415e85 0x10103b7 0x1010e55 0xfffd91 0xffeed7 0xffe285 0xffdd97 0xffd4aa 0x47b9e1
#	0x10103b6	github.com/ethpandaops/dora/indexer/beacon.(*forkCache).checkForkDistance+0x156	/home/runner/work/dora/dora/indexer/beacon/forkcache.go:221
#	0x1010e54	github.com/ethpandaops/dora/indexer/beacon.(*forkCache).processBlock+0x334	/home/runner/work/dora/dora/indexer/beacon/forkcache.go:338
#	0xfffd90	github.com/ethpandaops/dora/indexer/beacon.(*Client).processBlock+0x3b0		/home/runner/work/dora/dora/indexer/beacon/client.go:367
#	0xffeed6	github.com/ethpandaops/dora/indexer/beacon.(*Client).processStreamBlock+0x36	/home/runner/work/dora/dora/indexer/beacon/client.go:266
#	0xffe284	github.com/ethpandaops/dora/indexer/beacon.(*Client).processBlockEvent+0xc4	/home/runner/work/dora/dora/indexer/beacon/client.go:169
#	0xffdd96	github.com/ethpandaops/dora/indexer/beacon.(*Client).runClientLoop+0x636	/home/runner/work/dora/dora/indexer/beacon/client.go:148
#	0xffd4a9	github.com/ethpandaops/dora/indexer/beacon.(*Client).startClientLoop+0x69	/home/runner/work/dora/dora/indexer/beacon/client.go:99

Minimal preset doesn't work

if config.yaml has minimal preset, dora becomes unhappy.

All nodes are still connected, but they all report that they stuck syncing at slot 1.

None of the slots seem to be proposed, even tho they were.

To repro:

kurtosis run github.com/kurtosis-tech/ethereum-package@bbusa/preset --args-file https://github.com/kurtosis-tech/ethereum-package/blob/bbusa/preset/.github/tests/minimal.yaml

Feature: visualize mev relay data APIs

conformant MEV relays host these data APIs:

https://flashbots.github.io/relay-specs/#/

it would be nice if there was an integration in dora.

thinking something like:

static configuration to point to a set of relay URLs
a page/tab/modal on dora that for each relay:
- shows the most recent (e.g. 4 epochs) of delivered payloads to proposers
- shows the most recent (e.g. 4 epochs) of builder submissions the relay has

Feature: Track EL block extra data and allow pattern search via filtered slots page

Feature Request:
Dora should index the EL block extra data field and allow pattern search via the filtered slots page

Gnosis chain preset

I'm trying to start the explorer for a Devnet based on the Gnosis Chain Preset. Currently, it fails with the following message:

time="2023-10-03T18:27:49Z" level=fatal msg="error reading config file: tried to use unknown chain-preset: gnosis"

Possible Solution:

Add Gnosis preset configuration to https://github.com/pk910/dora/tree/master/config. Perhaps including https://github.com/gobitfly/eth2-beaconchain-explorer/blob/master/config/gnosis.chain.yml

possible to include the 'interop' config by prysm ?

I am trying to use dora against a local devnet created via prysm interop but get an unknown chain-preset

Feature: Track deposits

Dora should be able to track & display deposits.

Add execution layer rpc pool logic (copy from assertoor)
Add deposits table to database
(idx, time, pubkey, deposit origin, deposit sender, amount, withdrawal creds, valid)
Add deposit contract log crawler

Store blobs in db / external storage

Currently, the explorer fetches blobs directly from the CL node via RPC calls.
This approach won't work once blobs expire and are removed from the CL node.

To allow showing blobs after expiration, it should be possible to store blobs in DB or on an external storage (eg. S3).
This should be optional, so blob storage does not get a dependency to run the explorer.

slot number ahead of block number on kaustinen

On kaustinen at least, it seems that the slot number is actually the block number (using a slot number of e.g. 74 yields the execution data for block number 74).

https://dora.kaustinen-testnet.ethpandaops.io/slot/74

But the block number itself is reported to be 116, which is wrong. If you look at the slots before and after, the block values are jumping widely, which has the result of the block numbers being AHEAD of the slot numbers. This should not happen on a testnet who merged at genesis.

blob sidecar index issue

Dora currently stores blob sidecars with commitment as primary key.
This causes issues when commitments are re-used in multiple blob transactions.
In this situation, dora would currently override the blob entry from the older block.
It's effectively removing the blob sidecar link from the old block, which is obviously wrong.