- Design and develop the next generation of scalable blockchain platforms, consisting of dynamic subnets, multi-level trees (L3+), with versatile Wasm-based execution runtimes, and content-addressed data access.
- Harden IPC’s security by designing and implementing mechanisms like fraud proofs, escape hatches, disaster recovery, and various attack defenses.
- Build the foundation of Filecoin scalability, unlocking new suite of data-oriented services (compute, AI training, inference, hot storage, aggregation, data pipelines, CDNs, and more)
- Maintain and evolve the Solidity smart contracts that orchestrate IPC interactions (e.g. checkpointing, messaging, subnet lifecycle, etc.)
- Create production-grade software that is reliable, resilient, efficient, upgradeable, and observable.
- Strengthen IPC’s guarantees by implementing and deploying zero-knowledge proofs (ZK) and verifiable computation (VC) systems.
fip: title: Actor events author: Raúl Kripalani (@raulk), Steven Allen (@stebalien) discussions-to: status: Draft type: Technical Core category: Core created: 2022-10-12 spec-sections:
[{ | |
"context": { | |
"code_cid": "baeaaaaa", | |
"method_num": 0 | |
}, | |
"point": { | |
"event": "Started", | |
"label": "" | |
}, | |
"consumption": { |
The purpose of the CARv2 + DAG store endeavour is to eliminate overhead from the deal-making processes with the mission of unlocking scalability, performance, and resource frugality on both miner and client side within the Filecoin network.
The definition of done is the removal of the Badger blockstore from all client and miner codepaths involved in storage and retrieval deals, and the transition
Authors: @kubuxu, @raulk.
- BaseFee - current going fee (unit FIL per gas) unit determined by the network required for a message to be included.
- FeeCap - field in a message, determines maximum BaseFee to be paid (unit FIL per gas)
- MaxFee - maximum amount user is willing to pay for the message in total (unit FIL)
- MaxFee = FeeCap * GasLimit
See this PR and conversation for context: libp2p/libp2p#86.
To create a script to migrate issues from go-libp2p inner repos to the top-level repo, applying labels along the way.
docker@worker1:~$ iperf3 -c 192.168.99.102 | |
Connecting to host 192.168.99.102, port 5201 | |
[ 4] local 192.168.99.103 port 54386 connected to 192.168.99.102 port 5201 | |
[ ID] Interval Transfer Bandwidth Retr Cwnd | |
[ 4] 0.00-1.00 sec 417 MBytes 3.50 Gbits/sec 1220 194 KBytes | |
[ 4] 1.00-2.00 sec 412 MBytes 3.46 Gbits/sec 1262 198 KBytes | |
[ 4] 2.00-3.00 sec 407 MBytes 3.41 Gbits/sec 1267 202 KBytes | |
[ 4] 3.00-4.00 sec 422 MBytes 3.54 Gbits/sec 1164 214 KBytes | |
[ 4] 4.00-5.00 sec 411 MBytes 3.45 Gbits/sec 1422 198 KBytes | |
[ 4] 5.00-6.00 sec 417 MBytes 3.50 Gbits/sec 1304 202 KBytes |
libp2p streams are full-duplex. Each party can read and write simultaneously on the conduit, and the underlying transport guarantees (or not) delivery, while the multiplexer also participates in congestion control. Yamux, for example, applies stream-scoped congestion control to curtail head-of-line blocking in some circumstances. Mplex is more simplistic and relies purely on TCP congestion control.
There's an active debate in go-libp2p to rethink the single Close()
method
#!/usr/bin/env bash | |
set -euo pipefail | |
IFS=$'\n\t' | |
repos=( | |
"git@github.com:libp2p/go-sockaddr.git" | |
"git@github.com:libp2p/go-reuseport.git" | |
"git@github.com:libp2p/go-mplex.git" | |
"git@github.com:libp2p/go-stream-muxer.git" | |
"git@github.com:libp2p/go-libp2p.git" | |
"git@github.com:libp2p/go-libp2p-transport.git" |