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
Copy file name to clipboardExpand all lines: README.md
+29-7Lines changed: 29 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,11 +19,30 @@
19
19
-[Contribute](#contribute)
20
20
-[License](#license)
21
21
22
+
23
+
## Notes for 0.9.0 and Electra
24
+
Release 0.9.0 of `chaind` brings with it support for the Electra hard fork. A significant change in Electra is that attestations now cover multiple committees. As such, there is a new column in the `t_attestations` table called `f_committee_indices`. The existing column, called `f_committee_index`, is deprecated and will no longer be populated from this release onwards.
25
+
26
+
Usually in these situations `chaind` would carry out an automatic migration of data, however mainnet has over 1 billion attestations and so any migration will take a large amount of time and storage. To avoid the upgrade locking out `chaind` updates there is _no_ automatic movement of this data, however there are a number of options for existing users:
27
+
28
+
* leave the data as-is. If this data is required then code to query the database will need to fetch data from either the `f_committee_index` or `f_committee_indices` columns, depending on the slot time at which `chaind` was updated to release 0.9.0.
29
+
* move the data manually. Data can be moved from one column to the other with the following SQL:
30
+
```sql
31
+
UPDATE t_attestations
32
+
SET f_committee_indices = ARRAY[f_committee_index]
33
+
,f_committee_index =NULL
34
+
WHERE f_committee_indices IS NULL
35
+
AND<slot conditions>
36
+
```
37
+
Where `<slot_conditions>` are conditions to restrict the attestations to a subset of all slots. This restriction is important, as otherwise the update will take a very long time and require significant disk space. It would be possible to migrate the data over time by migrating a smaller number (e.g. 100000) slots at a time.
38
+
39
+
Note that although `f_committee_index` is now deprecated it is not removed by the update, due to the data not being automatically migrated. If a manual migration is completed then the column can be safely dropped, as it is no longer referenced within the `chaind` codebase.
40
+
22
41
## Install
23
42
24
43
### Binaries
25
44
26
-
Binaries for the latest version of `chaind` can be obtained from [the releases page](https://github.com/wealdtech/chaind/releases/latest).
45
+
Binaries for the latest version of `chaind` can be obtained from [the releases page](https://github.com/wealdtech/chaind/releases/latest).
27
46
28
47
### Docker
29
48
@@ -38,7 +57,7 @@ docker pull wealdtech/chaind
38
57
`chaind` is a standard Go binary which can be installed with:
39
58
40
59
```sh
41
-
GO111MODULE=on go get github.com/wealdtech/chaind
60
+
go install github.com/wealdtech/chaind@latest
42
61
```
43
62
44
63
## Usage
@@ -53,8 +72,13 @@ Data gathers four pieces of information from the beacon node, broken down by the
53
72
- proposer slashings
54
73
- attester slashings
55
74
- deposits
56
-
- voluntary exits; and
57
-
-**Ethereum 1 deposits** The Ethereum 1 deposits module provides information on deposits made on the Ethereum 1 network;
75
+
- voluntary exits
76
+
- BLS to execution change requests
77
+
- blobs
78
+
- deposit requests
79
+
- withdrawal requests
80
+
- consolidation requests
81
+
-**Ethereum execution deposits** The Ethereum execution deposits module provides information on deposits made on the Ethereum execution network;
58
82
-**Finalizer** The finalizer module augments the information present in the database from finalized states. This includes:
59
83
- the canonical state of blocks.
60
84
@@ -77,9 +101,7 @@ You can also run chaind using the example docker-compose file, it setups the Pos
77
101
`chaind` supports Teku and Lighthouse beacon nodes. The current state of obtaining data from beacon nodes is as follows:
78
102
79
103
- Teku: must be run in [archive mode](https://docs.teku.consensys.net/en/latest/Reference/CLI/CLI-Syntax/#data-storage-mode) to allow `chaind` to obtain historical data
80
-
- Lighthouse: Make sure to run with `--slots-per-restore-point 64 --reconstruct-historic-states --genesis-backfill`, else fetching historical information will be **very** slow. For more information on the trade off between Freezer DB size and fetching performance, please refer to [Database Configuration](https://lighthouse-book.sigmaprime.io/advanced_database.html) in the Lighthouse Book.
81
-
82
-
At current Prysm is not supported due to its lack of Altair-related information in its gRPC and HTTP APIs. We expect to be able to support Prysm again soon.
104
+
- Lighthouse: Make sure to run with `--reconstruct-historic-states --genesis-backfill --disable-backfill-rate-limiting`,otherwise fetching historical information will be **very** slow. For more information please refer to the [Advanced Database Configuration](https://lighthouse-book.sigmaprime.io/advanced_database.html) section in the Lighthouse Book.
83
105
84
106
`chaind` supports all execution nodes. The current state of obtaining data from execution nodes is as follows:
0 commit comments