profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Kubuxu/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Jakub Sztandera Kubuxu Protocol Labs Kraków, Poland Software Engineer at Protocol Labs working on @ipfs

jbenet/ipfs-screencap 45

Capture screenshots, publish them to IPFS, and copy the link to the clipboard.

hyperboria/services 30

Services on Hyperboria

calclavia/Electrodynamics 12

Electrodynamics is a voxel game mod that features realistic, world-based technology advancement systems.

jbenet/go-is-domain 11

Checks whether a string is a domain

filecoin-project/chain-validation 10

(DEPRECATED) See https://github.com/filecoin-project/test-vectors instead. (was: chain validation tools)

ipfs/go-ipfs-keystore 8

go-ipfs-keystore provides an interface and implementation of key storage for IPFS

filecoin-project/go-storage-miner 7

A Filecoin storage miner

filecoin-project/storage-fsm 6

A finite state machine used for sector storage

ipfs/go-metrics-prometheus 5

Prometheus bindings for go-metrics-interface

PullRequestReviewEvent
CommitCommentEvent

push eventfilecoin-project/lotus

Travis Person

commit sha ac2194b0eb255f5a51d75623014344e23399b3e5

sync branch main with master on updates

view details

Jakub Sztandera

commit sha 7e933f70457cb6c35c7be365df116d40f859633d

Merge pull request #7366 from filecoin-project/feat/sync-master-main sync branch main with master on updates

view details

push time in 2 days

delete branch filecoin-project/lotus

delete branch : feat/sync-master-main

delete time in 2 days

PR merged filecoin-project/lotus

sync branch main with master on updates

This will forcefully update the branch main to the git ref that triggered the workflow. This will keep the branch main in sync with the branch master at all times.

This requires that workflows have write permissions (which I believe they already do).

image


address the first item in #7356

+14 -0

1 comment

1 changed file

travisperson

pr closed time in 2 days

PullRequestReviewEvent
CommitCommentEvent
CommitCommentEvent

pull request commentfilecoin-project/specs-actors

updating linter version to stop segfaults on my machine

We should change the github.com/golangci/golangci-lint/pkg/lint in tools.go to github.com/golangci/golangci-lint/cmd/golangci-lint.

The huge require block in go.mod is most likely expected due to the new Go's module pruning stuff.

laudiacay

comment created time in 3 days

created tagKubuxu/go-no-map-range

tagv0.0.2

created time in 3 days

push eventKubuxu/go-no-map-range

Jakub Sztandera

commit sha 232e5789eccbe70cd022acc4449f434ef4dcfcbf

Update deps Signed-off-by: Jakub Sztandera <kubuxu@protocol.ai>

view details

push time in 3 days

issue openedfilecoin-project/FIPs

Flag Actor for use in payment channel protocols

Filecoin Payment Channel protocol supports Hash, Min- and Max-Time locks as well as message execution conditional lock. The message execution lock is currently limited in usability as there aren't many useful endpoints to call.

Background

Payment Channels in Filecoin operate on vouchers which can be thought of as contracts between two parties agreeing on a balance between them. These vouchers can have additional validity conditions:

  • Minimum time lock - the earliest time the voucher can be redeemed
  • Maximum time lock - the latest time the voucher can be redeemed
  • Hash lock - voucher is only valid if it is presented in combination with some "secret" value; if the redeemer doesn't know the value, the voucher cannot be redeemed
  • Message Execution lock - the voucher is only valid if a send of (To, Method, Param) (embedded in the voucher) succeeds.

While the first three are easy to use and fully enabled, the last one is limited by available endpoints of Filecoin actors.

Some Payment Channel Network (PCN) protocols require a global on-chain "flag", which all vouchers in a given voucher chain can refer to. See Blitz. The cleanest way to implement such a flag is the Message Execution lock and new actor type.

Flag Actor

I'm proposing a new Flag Actor, which is capable of the following:

  • Retaining a set of flags in the form of RLE+ (run-length encoded bitfield)
  • Delaying the act of setting a flag for Y epochs, Y being actor initialisation time constant (this is a requirement of some PCN protocols)
  • Checking the given set of flags sum to x. This allows checking if all flags are set or unset.
  • Checking the given set of flags sum to x mod 2. This allows for retractable flags.
  • Setting a set of flags restricted to the creator of the actor.

The action of clearing a flag is explicitly not supported. Most protocols using global flags require that they cannot be retracted.

Flags and flag sets can be expressed as RLE+. A way of delaying flags needs to be investigated, with the aim of not causing significant misestimations.

created time in 3 days

pull request commentfilecoin-project/FIPs

create fip draft to require peerid when multiaddr is set

There is a use case (not implemented today) for just multiaddr. It would be a dnsaddr that resolves to multiaddr+PeerID pair.

It can be useful as it allows the miner to dynamically change the IP, port, protocol and PeerID of deal nodes. This would for example allow load balancing.

jennijuju

comment created time in 4 days

pull request commentfilecoin-project/FIPs

Snap Deals draft

I applied @nicola 's feedback. Feel free to merge to assign FIP number. Additional rounds of changes will happen after that.

Kubuxu

comment created time in 4 days

push eventKubuxu/FIPs

Jakub Sztandera

commit sha e2f72f0ed4d82b923269c795c2b00a1979b0c3a2

Snap Deals draft Signed-off-by: Jakub Sztandera <kubuxu@protocol.ai>

view details

push time in 4 days

push eventKubuxu/FIPs

Jakub Sztandera

commit sha b45a69c949157e4c679b499ed9669ffaa9798e1a

fixup! Snap Deals draft Signed-off-by: Jakub Sztandera <kubuxu@protocol.ai>

view details

push time in 4 days

Pull request review commentfilecoin-project/FIPs

Snap Deals draft

+---+fip: XXXX+title: Snap Deals+author: @Kubuxu, @lucaniz, @nicola, @rosariogennaro, @irenegia+discussions-to: https://github.com/filecoin-project/FIPs/issues/145+status: Draft+type: Core+created: 2021-08-24+spec-sections: +  - miner actors+  - lotus mining++---++## Simple Summary++A one-message protocol for updating any sector with new data without re-sealing.++## Abstract++Storage provider embeds deal data into existing sector replica with some unpredictable randomness by "xor"-ing.++The miner generates one message which proves that sector was updated with new data.++## Change Motivation++Since 90+% of sectors in the Filecoin Network are CC sectors, having a protocol that allows for updating CC sectors to store real data without incurring in a full re-sealing would massively improve our network in terms of the amount of real data stored through it. ++1. It would allow **decoupling sealing latency from deal-making speed** - offering storage clients an improved experience for how quickly their data can land in on-chain deals+2. It would **unlock the 8EiB of storage already committed to the Filecoin network** to be quickly used for deals - enabling a 100PiB+ client to make deals for their entire dataset with a single miner like [f0127595](https://filfox.info/en/address/f0127595) which already has 120PiB of committed capacity.+3. It makes **utilizing existing committed capacity much cheaper for miners** (since they’ve already invested the sealing cost), increasing the chances they pay clients to add FIL+ data to these sectors.++What this FIP does not support (see Future Work section):+* Deal updates+* Moving deals across sectors++## Specification++### Nomenclature+**SectorKeyCID** - on-chain commitment of CC sector replica++**UnsealedSectorCID** - commitment of deal data generated from PieceCIDs++**SealedSectorCID** - commitment of sector replica with deals embedded in it++**EncodingRand** - collection of **HashNumber** randomness values used for encoding process++**Poseidon-128** - SNARK friendly hash function+++### Parameters++**ChallengeNumber** = 2200 - number of challenges to be proven++**HashNumber** = 512 - number of hashes used for randomness in encoding process

Renamed to HashShards reopen if you think something fits better.

Kubuxu

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentfilecoin-project/FIPs

Snap Deals draft

+---+fip: XXXX+title: Snap Deals+author: @Kubuxu, @lucaniz, @nicola, @rosariogennaro, @irenegia+discussions-to: https://github.com/filecoin-project/FIPs/issues/145+status: Draft+type: Core+created: 2021-08-24+spec-sections: +  - miner actors+  - lotus mining++---++## Simple Summary++A one-message protocol for updating any sector with new data without re-sealing.++## Abstract++Storage provider embeds deal data into existing sector replica with some unpredictable randomness by "xor"-ing.++The miner generates one message which proves that sector was updated with new data.++## Change Motivation++Since 90+% of sectors in the Filecoin Network are CC sectors, having a protocol that allows for updating CC sectors to store real data without incurring in a full re-sealing would massively improve our network in terms of the amount of real data stored through it. ++1. It would allow **decoupling sealing latency from deal-making speed** - offering storage clients an improved experience for how quickly their data can land in on-chain deals+2. It would **unlock the 8EiB of storage already committed to the Filecoin network** to be quickly used for deals - enabling a 100PiB+ client to make deals for their entire dataset with a single miner like [f0127595](https://filfox.info/en/address/f0127595) which already has 120PiB of committed capacity.+3. It makes **utilizing existing committed capacity much cheaper for miners** (since they’ve already invested the sealing cost), increasing the chances they pay clients to add FIL+ data to these sectors.++What this FIP does not support (see Future Work section):+* Deal updates+* Moving deals across sectors++## Specification++### Nomenclature+**SectorKeyCID** - on-chain commitment of CC sector replica++**UnsealedSectorCID** - commitment of deal data generated from PieceCIDs++**SealedSectorCID** - commitment of sector replica with deals embedded in it++**EncodingRand** - collection of **HashNumber** randomness values used for encoding process++**Poseidon-128** - SNARK friendly hash function+++### Parameters++**ChallengeNumber** = 2200 - number of challenges to be proven++**HashNumber** = 512 - number of hashes used for randomness in encoding process+++### One-messages Update Protocol+1. **Miner accepts and publishes storage deals (using PublishStorageDeals)**+2. **Miner updates an existing replica with deals**:+	1. Generate `EncodingRand = Poseidon-128(ComputeUnsealedCID(P1, P2, P3, ...), i)` for `i in [0, HashNumber)`+	where `P1, P2, P3, ...` are pieces corresponding to deals that will included in this sector.+	2. Encode the deal data into existing replica using `newReplica[i] = Enc(sectorKey[i], data[i], EncodingRand[i * HashNumber // NodeSectorSize)` function:+		- `newReplica` is the vector of `Fr` elements of the new replica+		- `sectorKey` is the vector of `Fr` elements of the CC sector replica data+		- `data` is the vector of `Fr` elements of the deals data ordered and padded as done in the sealing subroutine+		- `NodeSectorSize` is size of the sector in nodes (32 byte chunks)+	3. Compute SealedSectorCID of the `newReplica`.+3. **Miner produces a proof of sector update.**+	Generate a SNARK that proves:+	1. Generation of ChallengeNumber challenges in batches of 8:+		1. For `j=0..ChallengeNumber//8`, `[_, c[8*j+7], c[8*j+6], ..., , c[8*j] = Split-31bit(Poseidon-128(SealedSectorCID, j)`.+		The `Split-31bit` splits the 255bit output of Poseidon-128 hash into 8 31 bit chunks and discards 7 high bits.+		2. `c[i] = c[i] mod NodeSectorSize`+	2. For each challenge `i=0..ChallengeNumber`,  `c = c[i]`+		1. Encoding: the following we correcty computed: `newReplica[c] = Enc(sectorKey[c], data[c], Poseidon-128(UnsealedSectorCID, c*HashNumber//NodeSectorSize)`+		2. Inclusion proofs:+			1. `newReplica[c]` is the opening of `UpdatingSectorCID` at position `c`+			2. `sectorKey[c]` is the opening of `CommRLast` from `SealedSectorCID` at position `c`+			3. `data[c]` is the opening of `UnsealedSectorCID` at position `c`++4. **Miner publishes `Miner.ProveReplicaUpdate(SectorID, NewSealedSectorCID, deals []DealID, Proof)`**:+	1. Verify the proof of correct data update:+		1. Check that `SectorID` was originally CC sector, and fetch `SectorKey` or if that is null use `SealedSectorCID`.+		2. Check that `SectorID` has no deals active that are not included in the `deals` param.+		3. Check that all `deals` are either already in `SectorID` or are to be activated.+		3. Compute `NewUnsealedSectorCID` (CommD) based on DealIDs and deal table.+		6. Verify that `proof` is valid for using inputs: `NewSealedSectorCID`, `NewUnsealedSectorCID`, `SectorKey`.+	2. Activate new deals in `deals` array.+	3. If `SectorKeyCID` is null, set it to `SealedSectorCID`+	4. Update `SealedSectorCID` to `NewSealedSectorCID`+	5. Update `UnsealedSectorCID` to `NewUnsealedSectorCID`+	6. TODO: Keep the last DeclareUpdate epoch to simplify future retrieval

It is CommD and old CommR, both are available.

Kubuxu

comment created time in 4 days

Pull request review commentfilecoin-project/FIPs

Snap Deals draft

+---+fip: XXXX+title: Snap Deals+author: @Kubuxu, @lucaniz, @nicola, @rosariogennaro, @irenegia+discussions-to: https://github.com/filecoin-project/FIPs/issues/145+status: Draft+type: Core+created: 2021-08-24+spec-sections: +  - miner actors+  - lotus mining++---++## Simple Summary++A one-message protocol for updating any sector with new data without re-sealing.++## Abstract++Storage provider embeds deal data into existing sector replica with some unpredictable randomness by "xor"-ing.++The miner generates one message which proves that sector was updated with new data.++## Change Motivation++Since 90+% of sectors in the Filecoin Network are CC sectors, having a protocol that allows for updating CC sectors to store real data without incurring in a full re-sealing would massively improve our network in terms of the amount of real data stored through it. ++1. It would allow **decoupling sealing latency from deal-making speed** - offering storage clients an improved experience for how quickly their data can land in on-chain deals+2. It would **unlock the 8EiB of storage already committed to the Filecoin network** to be quickly used for deals - enabling a 100PiB+ client to make deals for their entire dataset with a single miner like [f0127595](https://filfox.info/en/address/f0127595) which already has 120PiB of committed capacity.+3. It makes **utilizing existing committed capacity much cheaper for miners** (since they’ve already invested the sealing cost), increasing the chances they pay clients to add FIL+ data to these sectors.++What this FIP does not support (see Future Work section):+* Deal updates+* Moving deals across sectors++## Specification++### Nomenclature+**SectorKeyCID** - on-chain commitment of CC sector replica++**UnsealedSectorCID** - commitment of deal data generated from PieceCIDs++**SealedSectorCID** - commitment of sector replica with deals embedded in it++**EncodingRand** - collection of **HashNumber** randomness values used for encoding process++**Poseidon-128** - SNARK friendly hash function+++### Parameters++**ChallengeNumber** = 2200 - number of challenges to be proven++**HashNumber** = 512 - number of hashes used for randomness in encoding process+++### One-messages Update Protocol+1. **Miner accepts and publishes storage deals (using PublishStorageDeals)**+2. **Miner updates an existing replica with deals**:+	1. Generate `EncodingRand = Poseidon-128(ComputeUnsealedCID(P1, P2, P3, ...), i)` for `i in [0, HashNumber)`+	where `P1, P2, P3, ...` are pieces corresponding to deals that will included in this sector.+	2. Encode the deal data into existing replica using `newReplica[i] = Enc(sectorKey[i], data[i], EncodingRand[i * HashNumber // NodeSectorSize)` function:+		- `newReplica` is the vector of `Fr` elements of the new replica+		- `sectorKey` is the vector of `Fr` elements of the CC sector replica data+		- `data` is the vector of `Fr` elements of the deals data ordered and padded as done in the sealing subroutine+		- `NodeSectorSize` is size of the sector in nodes (32 byte chunks)+	3. Compute SealedSectorCID of the `newReplica`.+3. **Miner produces a proof of sector update.**+	Generate a SNARK that proves:+	1. Generation of ChallengeNumber challenges in batches of 8:+		1. For `j=0..ChallengeNumber//8`, `[_, c[8*j+7], c[8*j+6], ..., , c[8*j] = Split-31bit(Poseidon-128(SealedSectorCID, j)`.+		The `Split-31bit` splits the 255bit output of Poseidon-128 hash into 8 31 bit chunks and discards 7 high bits.+		2. `c[i] = c[i] mod NodeSectorSize`+	2. For each challenge `i=0..ChallengeNumber`,  `c = c[i]`+		1. Encoding: the following we correcty computed: `newReplica[c] = Enc(sectorKey[c], data[c], Poseidon-128(UnsealedSectorCID, c*HashNumber//NodeSectorSize)`+		2. Inclusion proofs:+			1. `newReplica[c]` is the opening of `UpdatingSectorCID` at position `c`+			2. `sectorKey[c]` is the opening of `CommRLast` from `SealedSectorCID` at position `c`+			3. `data[c]` is the opening of `UnsealedSectorCID` at position `c`++4. **Miner publishes `Miner.ProveReplicaUpdate(SectorID, NewSealedSectorCID, deals []DealID, Proof)`**:+	1. Verify the proof of correct data update:+		1. Check that `SectorID` was originally CC sector, and fetch `SectorKey` or if that is null use `SealedSectorCID`.

There is no reason to store additional copy of CommR on-chain if it isn't required.

Kubuxu

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentfilecoin-project/lotus

lotus shed: fr32 utils

+package main++import (+	"io"+	"os"++	"github.com/urfave/cli/v2"+	"golang.org/x/xerrors"++	"github.com/filecoin-project/go-state-types/abi"+	"github.com/filecoin-project/lotus/extern/sector-storage/fr32"+)++var fr32Cmd = &cli.Command{+	Name:        "fr32",+	Description: "fr32 tools",+	Subcommands: []*cli.Command{+		fr32WriteCmd,+		fr32ReadCmd,+	},+}++var fr32WriteCmd = &cli.Command{+	Name:  "write",

Maybe give it similar semantics as base64 and other encoding decoding commands. Encode by default, decode with -d flag. Not sure.

magik6k

comment created time in 4 days

pull request commentfilecoin-project/bellperson

Add select and lookup gadgets

Also it turns out the gadgets already exist over here: https://github.com/filecoin-project/rust-fil-proofs/blob/master/storage-proofs-core/src/gadgets/insertion.rs#L287

Kubuxu

comment created time in 9 days

PR closed filecoin-project/bellperson

Add select and lookup gadgets

select gadget is one constraint and lookup gadget is N-1 constraints for N value lookup. If there is a better way to write them, or a better place to put them let me know.

+124 -0

1 comment

1 changed file

Kubuxu

pr closed time in 9 days

pull request commentfilecoin-project/bellperson

Add select and lookup gadgets

Will move it to rust-fil-proofs/core

Kubuxu

comment created time in 9 days

push eventKubuxu/bellperson

Jakub Sztandera

commit sha d78dac8f56ee4878c0ed7a25368230def8b51880

Add select and lookup gadgets Signed-off-by: Jakub Sztandera <kubuxu@protocol.ai>

view details

push time in 10 days

PR opened filecoin-project/bellperson

Add select and lookup gadgets

select gadget is one constraint and lookup gadget is N-1 constraints for N value lookup. If there is a better way to write them, or a better place to put them let me know.

+128 -0

0 comment

1 changed file

pr created time in 10 days

create barnchKubuxu/bellperson

branch : feat/lookup-gadget

created branch time in 10 days