Closed jsoares closed 1 year ago
With the end of project B1 (#4), we're kickstarting B3 this week! More details coming soon.
Short term goal: Eudico garden deployment with FVM integration and create and updated picture of HC.
FVM_EXPERIMENTAL
feature.
async
async
f04
(probably soon to be renamed f05
) address to follow spec
f04
address and SubnetID
to follow spec and fix interoperability with Rust.f04 address
and interoperability between Go and Rust.experimantal/fvm-m2
branch of Eudico. async
builtin-actors
, ref-fvm
, filecoin-ffi
).experimental/fvm-m2
we require the use of "fork-of-forks" with several potential sources of changes that need to be rebased periodically. This imposes a great overhead to keep up to date. The proposed plan is:
experimental/fvm-m2
or our new features in eudico
, we'll implement the full integration, and then worry about rebasing the latest changes in the corresponding repos.Runtime
are currently slightly different.
CrossMessage
field. This would overcome backward-compatibility issues with non-HC filecoin versions.SCA
. async
CrossMessages
field in blockchain blocks that broke the backward-compatibility with the Filecoin mainnet. As suggested in the spec, we've decided to include cross-messages in blocks as SECPK messages without a signature (once we start the process of merging into Lotus maybe the Lotus team let us add a NO_SIGNATURE
message type for this case).async
SubnetID
and `f04 addresses' .validation
functions into a Consensus
interface. From the reviews I learned where I can get a snapshot for the calibnet
testnet and check if Forest still syncs. Also that it cannot sync from Genesis because it only supports the latest Network Version (NV16) and doesn't have migrations. Tried syncing with mainnet but it failed because of this. The mainnet snapshot is over 70GB, testnet is ~4GB.weight
function into the Consensus
interface.t0100
but I don't understand how the first block can be mined without t0100
already being associated with a key that can sign the block. Unless I misunderstand what a "message" is (I thought it was a block or a transaction), the miner key has to be in the parent ledger already.
./eudico delegated genesis
command receiving the key of the miner as an input). The command initializes a new genesis miner with that key, and sets it as the validator. However, genesis miners are assigned a sequential ID address from t0100
onwards in genesis, thus the t0100
.async
lotus-stats
was just up. See next updatelotus-stats
and its supplimentary docker-compose services. The lotus-stats
command seems not working out of the box now, there are some custom configuration and code modification needed to spin up the service. The changes are also included in the above PR.lotus-stats
. Most likely with create another cmd: eudico-stats
to expose the metrics.eudico-stats
.async
eudico-stats
to export collected metrics. The changes are also included in the above PR.grafana
dashboard to expose the above metricsHierarchical Consensus clarifications and sync meeting
async
CarReader
struct; it is "hidden" in a method of CarHeader
.NetworkVersion
, not just the starting version of the original Filecoin network. It turned out that actually when we failed in our previous attempt, it was already producing a genesis with the latest version 16. The reason Forest refused it wasn't that the state tree was in a wrong format, but rather that the acceptable V8 Actor code CIDs hardcoded in Forest only accepted mainnet
and calibnet
. After further investigation it turned out I accidentally prepared a devnet
genesis from Lotus; this depends on how it is compiled. mainnet
and calibnet
, I can only prepare a genesis.car
file for devnet
, ie. when Lotus is compiled as make 2k
or make debug
, otherwise it complains that some minimum 2048 allowance is too low. devnet
Actor CIDs to Forest, and then debugging the config issues.async
@cryptoAtwill
Node Graph
, but Node Graph
does not support custom data structure. This implies that grafana might not be able to present the graph data until Node Graph
supports more data structure. One potential solution is to give up graph data. But this is not optimal as a graph should be the most clear way to represent cross net communication. The other solution is to use a graph database, such as neo4j
then build dashboard on top of neo4j
. This approach is better. But the issue with this approach is stats collection needs to be done offchain which currently it's done on chain. See next point for more ellaboration.eudico-stats
as part of FullNode API and can trigger as separate process, commit: https://github.com/filecoin-project/eudico/pull/233/commits/a43ee3c02ed3b469c4a47b583500a8970fcdf435. With this, the metric collections are completely off chain. It is possible to constanly send the collected subnet metric snapshot to external database for data processing. Currently only the parent child subnet relationship is tracked.@guy-goren
@aakoshh
neo4j
as metric databasesubnet count
in to neo4jasync
blstrs
library to upgrade its blst
dependency to a version that Narwhal also accepts, to get the thing to compile. Overall it's probably not a good idea to always compile such a heavy dependency stack as part of Forest, but let's see how it goes.async
@adlrocha:
@aakoshh:
(account ID, nonce)
pairs. Then, whenever the Filecoin chain is extended with a new block, we ask the mempool again if there are any new transactions we could send, by passing in the previously sent (account ID, nonce)
pairs as a filter, so we only consider the next nonce. This allows blocks made by other validators to unblock transactions we have, and also it treats pending nonces as if their predecessors were already included on the chain, even if they are not. Block will come at a steady pace from Narwhal, so it's a decent signal, but there can be too many actually, one per validator in each round. There will be a flag indicating whether this check is already happening, in which case we can skip doing it. @guy-goren:
experimental/fvm-m2
to have the base branch to start the implementation for Builder Net. async
The work continues in #7
@jsoares commented on Wed Nov 24 2021
Description
Turn the hierarchical consensus system prototype developed in B1 (#4) into a production-ready system.
Scope
Note that actual production deployment is beyond the scope and depends on the FIL team.
Dependencies
4
Resources
Papers
soonβ’οΈ
Talks
2022-06-22, Hierarchical consensus: A horizontal scaling framework for blockchains
Demos
2022-04-07, Eudico garden: a devnet for hierarchical consensus, running Tendermint, PoW, and Filecoin root consensus
2022-07-08, Draft of the Hierarchical Consensus spec