| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | ID | Dependencies | Description | Size | Done | Reference | Milestone | Github | Time Estimate | |||||||||||||||||||
2 | identify_tendermint_target | Figure out which version of Tendermint to build against. We need ABCI++ | XS | https://github.com/tendermint/tendermint/issues/9053 | M1 | https://github.com/consensus-shipyard/fendermint/issues/1 | 0.5 | |||||||||||||||||||||
3 | init_repo | Create a repository for the Tendermint IPC project. | XXS | https://github.com/consensus-shipyard/fendermint | M1 | 0.25 | ||||||||||||||||||||||
4 | rust_proto_abci_interface | identify_tendermint_target | Compile the Tendermint ABCI++ protobuf interfaces to Rust | M | https://github.com/informalsystems/tendermint-rs/tree/main/tools/proto-compiler | M1 | https://github.com/consensus-shipyard/fendermint/issues/3 | 3 | ||||||||||||||||||||
5 | setup_ci | rust_proto_abci_interface, init_repo | Setup a CI pipeline to build the project. Check what teams like FVM are using. | S | M1 | https://github.com/consensus-shipyard/fendermint/pull/5 | 1 | |||||||||||||||||||||
6 | impl_eth_rpc_api_query | rust_proto_abci_interface, dep_builtin_actors | Some of the Ethereum JSON-RPC API should be implemented using ABCI Query interface. Lotus implemented something, to be compatible with Web3 tools that work with Ethereum. If full coverage is needed (e.g. eth_sendTransaction), we'd probably need something like an API facade to translate to the Tendermint model, but some queries about state (e.g. eth_getStorageAt) would be implemented via ABCI. We can look at Ethermint, which supports the Ethereum JSON-RPC API over Tendermint and Cosmos. | XXL | https://openethereum.github.io/JSONRPC-eth-module https://docs.ethermint.zone/quickstart/events.html#ethereum-json-rpc-events https://docs.ethermint.zone/basics/json_rpc.html https://app.slack.com/client/TEHTVS1L6/C0330PQ7TBK/thread/C0330PQ7TBK-1682674148.637349?cdn_fallback=2 | M2 | https://github.com/consensus-shipyard/fendermint/issues/99 | 21 | ||||||||||||||||||||
7 | eth_ecosystem_tools | impl_eth_rpc_api_query | Integrate with Meta Mask, Truffle, Remix, etc. | XL | M2 | https://github.com/consensus-shipyard/fendermint/issues/132 | 8 | |||||||||||||||||||||
8 | ipld_persistent_blockstore | Take the IPLD persistent blockstore implementation from Forest. | S | M1 | https://github.com/consensus-shipyard/fendermint/issues/6 | 1 | ||||||||||||||||||||||
9 | dep_builtin_actors | Figure out which version of the FVM builtin-actors to use and link to them. | XXS | M1 | https://github.com/consensus-shipyard/fendermint/issues/8 | 0.25 | ||||||||||||||||||||||
10 | dep_fvm | Figure out which version of the FVM library to use and add it to the project. | XXS | M1 | https://github.com/consensus-shipyard/fendermint/issues/8 | 0.25 | ||||||||||||||||||||||
11 | define_self_contained_tx_types | dep_fvm | Define types for transactions arriving from users, without the need to resolve CIDs. Look at what messages the built-in actors expect, what signatures Filecoin supports, how accounts are identified. Use the Filecoin message type from Forest if possible. | S | M1 | https://github.com/consensus-shipyard/fendermint/issues/11 | 1 | |||||||||||||||||||||
12 | define_tx_binary_format | define_self_contained_tx_types | Define how transactions should be serialized to binary format in the blocks. Use the same format as Forest, if possible. | S | M1 | 1 | ||||||||||||||||||||||
13 | arbitrary_for_tx | define_self_contained_tx_types | Define Arbitrary transaction generators, to be used with QuickCheck tests. | S | M1 | https://github.com/consensus-shipyard/fendermint/pull/31 | 1 | |||||||||||||||||||||
14 | quickcheck_for_tx_ser | define_tx_binary_format, arbitrary_for_tx | Create some tests that generate random transactions and serialize them, to serve as examples of input as well as protect against regressions. | S | M1 | https://github.com/consensus-shipyard/fendermint/pull/32 | 1 | |||||||||||||||||||||
15 | impl_block_execution | rust_proto_abci_interface, dep_fvm, dep_builtin_actors | Implement the FinalizeBlock method in ABCI++ and execute transactions against the FVM, returning the final state root hash as application state. | L | https://github.com/tendermint/tendermint/tree/main/spec/abci | M1 | https://github.com/consensus-shipyard/fendermint/issues/13 | 5 | ||||||||||||||||||||
16 | impl_balance_query | rust_proto_abci_interface, dep_builtin_actors | Implement an ABCI++ query that returns a user balance. | M | https://docs.ethermint.zone/core/pending_state.html | M1 | https://github.com/consensus-shipyard/fendermint/issues/34 | 3 | ||||||||||||||||||||
17 | define_genesis_type | dep_builtin_actors, rust_proto_abci_interface | Create types for initiating the ledger state of the actors. Starting balances, public keys,and the Tendermint power distribution. See what exists in Lotus / Forest as a guideline. | M | M1 | https://github.com/consensus-shipyard/fendermint/issues/39 | 3 | |||||||||||||||||||||
18 | arbitrary_for_genesis | define_genesis_type | Arbitrary instances for Genesis types. | S | M1 | https://github.com/consensus-shipyard/fendermint/pull/43 | 1 | |||||||||||||||||||||
19 | quickheck_for_genesis_serde | cbor_for_genesis, arbitrary_for_genesis | Quickcheck tests for serializing and deserializing Genesis data from CAR, to serve as examples and regression protection. | S | M1 | https://github.com/consensus-shipyard/fendermint/pull/43 | 1 | |||||||||||||||||||||
20 | cbor_for_genesis | define_genesis_type | Implement CBOR for the Genesis type so it can be constructed in the Subnet Actor and imported by the subnet. It could be a large task if there's a lack of support for writing CARs. CAR files were the way Lotus exported a State Tree. But we can also just construct a purpose made Genesis spec and treat it as CBOR, and it's up to the subnet to initialise itself from it by building up the State Tree. | S | M1 | https://github.com/consensus-shipyard/fendermint/pull/43 | 1 | |||||||||||||||||||||
21 | impl_init_from_genesis | define_genesis_type, cbor_for_genesis | Implement the part of ABCI that initializes the ledger from the Genesis data. This can be huge and arduous, with intimate knowledge of built-in actor storage layouts. Forest can't do it. Lotus can. | XL | https://github.com/anorth/fvm-workbench initialises actor state | M1 | https://github.com/consensus-shipyard/fendermint/issues/41 | 8 | ||||||||||||||||||||
22 | state_machine_test_for_exec | impl_init_from_genesis, arbitrary_for_genesis, impl_block_execution, arbitrary_for_tx, impl_balance_query | Implement an integration test against the ABCI++ interface (or something a internal, so we can isolate ourselves from the Tendermint block type) that generates random batches transfer messages between accounts and checks the resulting balances, starting from some random genesis state. | L | M1 | 5 | ||||||||||||||||||||||
23 | app_abci_grpc | rust_proto_abci_interface, state_machine_test_for_exec | Create a service component that listens to gRPC (or maybe the raw TCP connection Tendermint uses) and serves the Application interface to Tendermint. | M | M1 | https://github.com/consensus-shipyard/fendermint/issues/3 | 3 | |||||||||||||||||||||
24 | app_config | Find a nice config library for the application. | S | M1 | https://github.com/consensus-shipyard/fendermint/issues/52 | 1 | ||||||||||||||||||||||
25 | app_main | app_config, app_abci_grpc, ipld_persistent_blockstore | Create an application binary that initializes the application stack. | S | M1 | 1 | ||||||||||||||||||||||
26 | app_docker | app_main | Dockerize the application. | S | M1 | https://github.com/consensus-shipyard/fendermint/pull/92 | 1 | |||||||||||||||||||||
27 | tendermint_docker | identify_tendermint_target | Build docker image from the right version of Tendermint. | S | https://github.com/informalsystems/tendermint-rs/tree/main/tools/docker | M1 | 1 | |||||||||||||||||||||
28 | smoke_test | app_main, identify_tendermint_target | Create a smoke test that actually starts the application process and Tendermint, and executes some transactions. Maybe even run the state machine tests. Maybe use docker-compose to start a test environment. | L | M1 | https://github.com/consensus-shipyard/fendermint/pull/92 | 5 | |||||||||||||||||||||
29 | validate_tx | impl_block_execution | Validate transactions during message execution: check signature, check account nonce, check fees. | M | M1 | https://github.com/consensus-shipyard/fendermint/pull/28 | 3 | |||||||||||||||||||||
30 | state_machine_test_gen_valid | state_machine_test_for_exec, validate_tx | Update state machine tests to generate valid transactions. | M | M1 | 3 | ||||||||||||||||||||||
31 | state_machine_test_gen_invalid | validate_tx | Generate invalid transactions in state machine tests and see them fail. | S | M1 | 1 | ||||||||||||||||||||||
32 | impl_check_tx | validate_tx | Implement the expected mempool checks: account nonces, signature checks. Not sure what else, need to check what Forest does. | S | Forest School | M1 | https://github.com/consensus-shipyard/fendermint/pull/28 | 1 | ||||||||||||||||||||
33 | MILESTONE_1 | impl_check_tx, smoke_test | Milestone 1 shows that we can run Tendermint with FVM and IPLD. | XS | M1 | 0.5 | ||||||||||||||||||||||
34 | MILESTONE_2 | eth_ecosystem_tools | Milestone 2 shows that we can use Ethereum tools on top of Tendermint. | XS | M2 | 0.5 | ||||||||||||||||||||||
35 | remove_unneeded_builtin_actors | dep_builtin_actors | We probably don't need all actors that are Filecoin specific. But I don't know how easy it is to only deploy some, from the bundle. | M | M3 | 3 | ||||||||||||||||||||||
36 | define_checkpoint_type | rust_proto_abci_interface | Define a type for checkpointing Tendermint and the application state, to be sent to the parent subnet. Think about what it needs: the previous committee signature signing over the reigns to the next committee. It should contain the next committee composition so the Subnet Actor in the parent knows who will sign the next checkpoint. The checkpoint can contain (typed!) CIDs so if nothing changed we can keep sending the same stuff. | M | M3 | https://github.com/consensus-shipyard/fendermint/issues/248 | 3 | |||||||||||||||||||||
37 | quickcheck_checkpoint_serde | define_checkpoint_type | Define arbitrary instances for checkpoints and create QuickCheck tests that demonstrate the format and protect against regressions. | S | M3 | 1 | ||||||||||||||||||||||
38 | staking_actor | dep_builtin_actors, dep_ipc_actors | Create a new user-defined actor in Rust for staking. It should be initialized from Genesis. When new validators want to join, they should go into a queue. At the end of the checkpointing period, it should apply all the queued stake changes, and return the updates, which must be gathered by the Application and returned to Tendermint. | L | M3 | https://github.com/consensus-shipyard/ipc-solidity-actors/pull/208 https://github.com/consensus-shipyard/ipc-solidity-actors/pull/212 | 5 | |||||||||||||||||||||
39 | staking_handle_bonding | staking_actor | Handle top-down messages that represent bonding. Put them in the queue. | M | M3 | https://github.com/consensus-shipyard/fendermint/issues/153 | 3 | |||||||||||||||||||||
40 | staking_handle_epoch | staking_handle_bonding | Handle the end-of-epoch where by draining the queue and returning power changes. It's not clear now how this actor should be called at the end of certain block heights. Cosmos calls each module at the end of a block, but do we have anything like this in Filecoin? I guess it could be something the application knows to do. | L | M3 | https://github.com/consensus-shipyard/fendermint/issues/152 https://github.com/consensus-shipyard/fendermint/issues/252 | 5 | |||||||||||||||||||||
41 | checkpoint_actor | dep_builtin_actors, define_checkpoint_type, staking_handle_epoch, dep_ipc_actors | Create a new user-defined actor in Rust for checkpointing. When the Tendermint block header height indicates that it's time for a new checkpoint, it should insert a new record into the ledger and wait for validator signatures. | M | M3 | https://github.com/consensus-shipyard/fendermint/issues/247 | 3 | |||||||||||||||||||||
42 | checkpoint_accumulate_sigs | checkpoint_actor | The checkpoint actor should handle messages from the previous-epoch validators over the checkpoints in the ledger and accumulate them. Make sure only validators staked in that epoch can sign. When enough power has been gathered, mark the checkpoint ready for sending to the parent subnet. | L | M3 | https://github.com/consensus-shipyard/fendermint/issues/249 | 5 | |||||||||||||||||||||
43 | app_sign_checkpoint | checkpoint_accumulate_sigs, app_main | If the node is run by a validator, it should sign the checkpoint and add a transaction to the Tendermint mempool. | M | M3 | https://github.com/consensus-shipyard/fendermint/issues/255 | 3 | |||||||||||||||||||||
44 | checkpoint_emit_event | checkpoint_accumulate_sigs | Once the checkpoint gathered enough signatures, emit an event to Tendermint. | S | M3 | https://github.com/consensus-shipyard/fendermint/issues/251 | 1 | |||||||||||||||||||||
45 | dep_ipc_actors | Find out what actors from Eudico can be reused here. | L | M3 | 5 | |||||||||||||||||||||||
46 | relayer_follow_tendermint | identify_tendermint_target | Find a library (in Rust if possible) that subscribes to events from a Tendermint node. Use it to point the relayer at Tendermint. | M | https://docs.rs/tendermint-rpc/0.31.1/tendermint_rpc/client/struct.WebSocketClient.html | M3 | 3 | |||||||||||||||||||||
47 | relayer_look_for_checkpoints | relayer_follow_tendermint, checkpoint_emit_event, define_checkpoint_type | The Tendermint follower should parse events and look for checkpoint event emissions that it can send to the parent. | S | M3 | https://github.com/consensus-shipyard/fendermint/issues/256 | 1 | |||||||||||||||||||||
48 | relayer_submit_to_lotus | relayer_signing_arrangement | Find a library (in Rust if possible) that we can use to send messages to Lotus. | M | M3 | https://github.com/consensus-shipyard/fendermint/issues/257 | 3 | |||||||||||||||||||||
49 | relayer_signing_arrangement | Figure out what exactly should be signed and by whom to be able to send to Lotus. Ideally the checkpoint group signature should be all we need, but that's not a Lotus message. Maybe the relayer needs its own account, with their own nonces and balance, and should receive rewards from the Subnet Actor. But then how many relayers. | L | M3 | 5 | |||||||||||||||||||||||
50 | relayer_config | Configuration for the relayer: which Tendermint node and Lotus node to connect to, what's the address of the Subnet Actor in the parent. | S | M3 | 1 | |||||||||||||||||||||||
51 | relayer_main | relayer_look_for_checkpoints, relayer_config, relayer_submit_to_lotus | Entry point for the relayer process that sends messages between Tendermint and Lotus. At this point it just sends Tendermint checkpoints to Lotus. | M | M3 | 3 | ||||||||||||||||||||||
52 | relayer_docker | relayer_main | Build a docker image from the relayer so we can add it to docker-compose. | S | M3 | 1 | ||||||||||||||||||||||
53 | lotus_subnet_actor | Create a subnet actor able to validate Tendermint checkpoints. | L | M3 | 5 | |||||||||||||||||||||||
54 | ipld_resolver_gossipsub | Figure out how to participate in the gossipsub protocol defined in the spec to serve IPLD content, when asked for it. | L | https://github.com/protocol/ConsensusLab/blob/main/specs/hierarchical_consensus.md#Subnet-Content-Resolution-Protocol | M3 | https://github.com/consensus-shipyard/ipc-agent/pull/44 | 5 | |||||||||||||||||||||
55 | ipld_resolver_storage | ipld_persistent_blockstore | Find a way the IPLD resolver could connect to the IPLD store used by the application. Not sure if this is possible with the underlying implementation. Maybe we have to go through the Application, or vice versa. | L | M3 | https://github.com/consensus-shipyard/ipc-agent/pull/53 | 5 | |||||||||||||||||||||
56 | ipld_resolver_config | Configuration for the resolver: where is the IPLD block store, what are the gossipsub addresses to connect to. | S | M3 | https://github.com/consensus-shipyard/ipc-agent/pull/49 | 1 | ||||||||||||||||||||||
57 | ipld_resolver_main | ipld_resolver_gossipsub, ipld_resolver_config, ipld_resolver_storage | Start an IPLD resolver process that connects to the IPLD store and is able to resolve CIDs that point at checkpoints, when the parent subnet needs them. | M | M3 | https://github.com/consensus-shipyard/ipc-agent/issues/37 | 3 | |||||||||||||||||||||
58 | ncmax_tx_types | Define the wrappers for for-execution/for-resolution meta-data that we can use to differentiate messages that contain CIDs for resolution or for execution. | S | https://eprint.iacr.org/2020/1101 | M3 | https://github.com/consensus-shipyard/fendermint/issues/189 | 1 | |||||||||||||||||||||
59 | ncmax_resolution_pool | Create a component in the application to hold proposed messages that contain CIDs that need to be resolved. Make it configurable what the minimum time messages have to spend in the pool is. This doesn't have to go into the ledger. If every node forgets a proposed CID, no problem, they can be re-proposed. | M | M3 | https://github.com/consensus-shipyard/fendermint/pull/201 | 3 | ||||||||||||||||||||||
60 | ipld_resolver_bidi_connection | ipld_resolver_main | The IPLD resolver should expose a TCP connection locally where it accepts CID resolution requests and will at some point, potentially, send resolved CIDs back. We can consider using libp2p, Session Types, or gRPC for this. Probably gRPC is the best if we want to reuse this for different implementations; it's a local, trusted interface anyway. | XL | M3 | https://github.com/consensus-shipyard/ipc-ipld-resolver | 8 | |||||||||||||||||||||
61 | ipld_resolver_resolve_graph | The IPLD resolver must be able to resolve CIDs via Gossipsub, Graphsync or Bitswap. This is different from ipld_resolver_gossipsub in that it can deviate from what the spec set out. | XXL | M3 | https://github.com/consensus-shipyard/ipc-agent/issues/17 | 21 | ||||||||||||||||||||||
62 | ipld_resolver_has_cid | ipld_resolver_bidi_connection | The IPLD resolver should be able to answer whether it has a CID already. | S | M3 | 1 | ||||||||||||||||||||||
63 | ipld_resolver_resolve_async | ipld_resolver_bidi_connection, ipld_resolver_resolve_graph | The IPLD resolver should accept asynchronous resolution requests. It should send a response message when the CID is resolved. | S | M3 | https://github.com/consensus-shipyard/fendermint/pull/210 | 1 | |||||||||||||||||||||
64 | ipld_resolver_resolve_sync | ipld_resolver_bidi_connection, ipld_resolver_resolve_graph | The IPLD resolver tries to resolve a CID synchronously, perhaps with a timeout. | M | M3 | 3 | ||||||||||||||||||||||
65 | ncmax_handle_tx_for_resolution | ncmax_tx_types, impl_block_execution, ipld_resolver_resolve_async | Handle proposed CIDs during block processing by adding them to the pool. When they are added, ask the IPLD resolver to procure the data. | S | M3 | https://github.com/consensus-shipyard/fendermint/pull/201 | 1 | |||||||||||||||||||||
66 | ncmax_handle_check_tx | ipld_resolver_resolve_async, ncmax_resolution_pool | Handle CIDs which Tendermint sends for checking by adding sending them for async resolution. | S | M3 | https://github.com/consensus-shipyard/fendermint/pull/198 | 1 | |||||||||||||||||||||
67 | ncmax_handle_resolved_tx | validate_tx, ipld_resolver_resolve_async, ncmax_resolution_pool | When notified that a CID is resolved, mark it as such so that it can be proposed next time. We can also use this step to run checks, perhaps. | S | M3 | https://github.com/consensus-shipyard/fendermint/pull/210 | 1 | |||||||||||||||||||||
68 | ncmax_get_propoposals | ncmax_resolution_pool | List proposals which have been marked as resolved and have spent enough time in the pool so that we expect most other nodes have it. | S | M3 | https://github.com/consensus-shipyard/fendermint/pull/203 | 1 | |||||||||||||||||||||
69 | ncmax_handle_tx_for_exec | ipld_resolver_resolve_sync, ncmax_tx_types, impl_block_execution | Implement block processing to that messages which are CIDs are synchronously resolved. | S | M3 | https://github.com/consensus-shipyard/fendermint/issues/197 | 1 | |||||||||||||||||||||
70 | relayer_follow_lotus | relayer_main | Find a way for a relayer to keep up with the results of a Lotus node and look for top-down messages in the results. | L | M3 | https://github.com/consensus-shipyard/fendermint/pull/206 | 5 | |||||||||||||||||||||
71 | relayer_submit_to_tendermint | relayer_main, ncmax_handle_check_tx | The relayer should package top-down messages as Tendermint transactions and send them to the child subnet. These can be sent as CIDs. Not sure if these have to be signed, or we're just happy that they have been legitimately included in the parent ledger, emitted by some actor. The transaction should contain meta-data about where it is in the Filecoin chain. | L | M3 | https://github.com/consensus-shipyard/fendermint/pull/231 | 5 | |||||||||||||||||||||
72 | parent_view_to_lotus | Add a component to the Application that it can ask whether a certain transaction is included in a certain Filecoin block, and whether that block has finalized on the parent chain. | L | This is what the "PoS Sidechains" paper calls "direct observation". In the pseudo code, in "Algorithm 9", this is realised by "mc_outgoing_tx". https://eprint.iacr.org/2018/1239.pdf | M3 | https://github.com/consensus-shipyard/fendermint/pull/205 | 5 | |||||||||||||||||||||
73 | abci_create_proposal | parent_view_to_lotus, ncmax_get_propoposals, ncmax_tx_types | Handle the request from ABCI++ to create a proposal by taking the resolved CIDs from the pool, perhaps validating it now (although it could take a long time and better done already). The self-contained transactions can be left in, these have been checked already. Top-down messages should be filtered so that they are finalized in the parent chain. | M | M3 | https://github.com/consensus-shipyard/fendermint/pull/203 | 3 | |||||||||||||||||||||
74 | abci_validate_proposal | parent_view_to_lotus, ncmax_tx_types, ipld_resolver_has_cid | Handle the request from ABCI++ to vote on a proposal, if it's acceptable. Check if all CIDs are available. Check if top-down messages have been finalized in the parent chain. | M | M3 | https://github.com/consensus-shipyard/fendermint/pull/202 | 3 | |||||||||||||||||||||
75 | ipc_from_tendermint_to_lotus | ipc_bottom_up_msg_types, relayer_main, ipld_resolver_gossipsub, app_sign_checkpoint, lotus_subnet_actor | IPC bottom-up messages are flowing from Tendermint to Lotus. | XXS | M3 | 0.25 | ||||||||||||||||||||||
76 | ipc_from_lotus_to_tendermint | ncmax_handle_tx_for_resolution, ncmax_handle_tx_for_exec, abci_create_proposal, abci_validate_proposal, ipc_top_down_msg_types, relayer_follow_lotus, relayer_submit_to_tendermint | IPC top-down messages are flowing from Lotus to Tendermint. | XXS | M3 | 0.25 | ||||||||||||||||||||||
77 | ipc_top_down_msg_types | staking_actor, dep_ipc_actors | Define types for actor initiated (ie. non-IPC related) messages that we deliver to whatever actor is the recipient. | S | M3 | https://github.com/consensus-shipyard/fendermint/pull/231 | 1 | |||||||||||||||||||||
78 | ipc_bottom_up_msg_types | checkpoint_actor, dep_ipc_actors | Define types for messages going from the subnet towards the parent. | S | M3 | https://github.com/consensus-shipyard/fendermint/pull/187 | 1 | |||||||||||||||||||||
79 | lotus_docker | Find a docker image of Lotus we can use in docker-compose | XS | M3 | 0.5 | |||||||||||||||||||||||
80 | ipc_docker_compose | tendermint_docker, app_docker, relayer_docker, lotus_docker | Build a docker-compose file where everything works together. It should have things like Prometheus and Grafana for monitoring. | S | M3 | https://github.com/consensus-shipyard/fendermint/pull/222 | 1 | |||||||||||||||||||||
81 | MILESTONE_3 | ipc_from_tendermint_to_lotus, ipc_from_lotus_to_tendermint, ipc_docker_compose | Milestone 3 shows that Tendermint works as a subnet of Lotus. | XS | https://docs.google.com/document/d/1cFoTdoRuYgxmWJia6K-b5vmEj-4MvyHCNvShZpyconU/edit# | M3 | 0.5 | |||||||||||||||||||||
82 | lurk_succint_what | checkpoint_actor, staking_actor | Think about what we could do with Lurk in the context of Tendermint. Maybe the checkpoints, perhaps that they resemble the power structure dictated by the Subnet Actor? | XXL | M4 | 21 | ||||||||||||||||||||||
83 | evidence_minor | ipc_from_tendermint_to_lotus | Figure out what kind of evidence of Byzantine behaviour we can send to the parent actor to slash an individual validator that misbehaves. This evidence can be signed by the majority of validators and be accepted as such. | L | M4 | 5 | ||||||||||||||||||||||
84 | evidence_major | Figure out if there's any way we could send envidence of the majority of subnet validators misbehaving, e.g. stealing funds. Full nodes in the subnet would get a consensus failure, but how to could they convince the parent subnet? One evidence type in this category is double signing a block at the same height by the same committee, which proves that the majority was dishonest. What's more difficult to prove is a corrupted ledger, falsified checkpoint messages. | XL | M4 | 8 | |||||||||||||||||||||||
85 | recursive_subnets | ipc_from_tendermint_to_lotus, ipc_from_lotus_to_tendermint, parent_view_to_tendermint | Demonstrate that at this point it is possible to create a subnet of a subnet, with Tendermint nodes on both levels. | L | M4 | 5 | ||||||||||||||||||||||
86 | validator_rewards | impl_block_execution | Validators in the subnet should get rewards, probably in a separate token from the parent subnet. | L | M4 | https://github.com/consensus-shipyard/fendermint/issues/169 | 5 | |||||||||||||||||||||
87 | relayer_reward_in_tendermint | relayer_submit_to_tendermint | Relayers should get rewards. | M | M4 | 3 | ||||||||||||||||||||||
88 | relayer_reward_in_lotus | relayer_submit_to_lotus | Relayers should get rewards. | L | M4 | 5 | ||||||||||||||||||||||
89 | parent_view_to_tendermint | A component which can indicate whether a top-down message is legit. | L | M4 | 5 | |||||||||||||||||||||||
90 | MILESTONE_4 | recursive_subnets, relayer_reward_in_tendermint, relayer_reward_in_lotus, evidence_minor, evidence_major | Milestone 4 shows recursive subnets and economics. | XS | M4 | 0.5 | ||||||||||||||||||||||
91 | ||||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||||
100 |