Describe the bug
I originally saw (in lotus code) and I read "period: 25", assuming that drand round is 25s.
Given our analysis there must be at least one drand entry per block (for the slow catchup mode to fully work). Having less than 1 drand per block allows miners to rush during catch-up on some epochs (e.g. if drand is 30 and lotus is 25, they can catch up every 5 blocks).
We do not have analysis that show that the impact of a single rush every few epochs is insecure nor that it insecure, however, we do know that one drand per round is secure.
Proposal 1: Change Filecoin blocktime: Set Filecoin block time to ≥30s
Proposal 2: Change Filecoin blocktime: Set Drand round time to ≤25s
Every SAFT purchaser will get his/her own individual actor (a.k.a. smart contract) that vests over the appropriate period. You can do two things with that actor:
Withdraw tokens that have vested
Change ownership of the actor using the SwapSigner method – this doesn’t let you withdraw more tokens, but it does let you transfer ownership of the actor to a new custodian or wallet.
If you choose to use a professional custodian (which we recommend for most people) rather than self-custody, CoinList will facilitate that for most purchasers. The custodian that CoinList will be working with by default will support SwapSigner , as will the self-custody wallet with Ledger support. Others may or may not – you should ask, and be aware that you might be stuck with the custodian if they don’t implement it.
There will be more instructions for SAFT purchasers via emails from Coinlist in the next few weeks!
每个SAFT购买者都将获得他/她自己的个人演员（也称为智能合约），在适当的时间内进行投资。你可以对那个演员做两件事： 收回已授予的代币 使用SwapSigner方法更改参与者的所有权-这不会让您提取更多的代币，但可以将参与者的所有权转移到新的保管人或钱包中。 如果您选择使用专业的保管人（我们建议大多数人使用）而不是自行保管，CoinList将为大多数购买者提供便利。CoinList将默认与之合作的托管人将支持SwapSigner，以及支持分类账的自助保管钱包。如果你不知道，他们可能会问你。 在接下来的几周里，Coinlist会给SAFT买家更多的指示！
We have other constructions in development, NSE and other options. They will be proposed as network upgrades through a FIP (Filecoin Improvement Proposal) after Mainnet launch. We hope to have at least one of these faster and cheaper constructions online within 6-12mo, but the development timeline depends on a lot of different constraints after mainnet launch. Note that new proofs will coexist with SDR, so a new cheaper proof will be optional to miners.
About NSE: NSE is one of the best candidates for a proof upgrade, and teams are working on implementation. But there are other candidates too, which are promising as well. It may be that another algorithm ends up better than NSE -- we don’t know yet. Proof upgrades will arrive after mainnet launch and will coexist.
Both the Proof of Replication and Proof of Spacetime processes in Filecoin use zk-SNARKs for compression.
zk-SNARKs stands for "Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge." You can think of them as hashes of computations. They let us prove that a proof has been done correctly without having to reveal the details of the proof itself or the underlying data on which it's based.
The process of creating Filecoin's zk-SNARKs is computationally expensive (slow), but the resulting end product is small and the verification process is very fast. Compared to the original proofs, zk-SNARKs are tiny, making them efficient to store in a blockchain. For example, a proof that would have taken up hundreds of kilobytes on the Filecoin chain can be compressed to just 192 bytes using a zk-SNARK.
As mentioned previously, everyone running a Filecoin node maintains an up-to-date version of the chain for verification purposes. Keeping each proof small with the assistance of zk-SNARKs minimizes the storage demands placed on each node in the Filecoin network, as well as the length of time it takes to verify a transaction.
Whereas the Proof of Replication is run once to prove that a miner stored a physically unique copy of the data at the time the sector was sealed, the Proof of Spacetime (PoSt) is run repeatedly to prove that they are continuing to dedicate storage space to that same data over time.
The Proof of Spacetime checks just a subpart of the data, running a probablistic proof on random locations to show that the miner has the specific bytes that should be there. Rather than checking for the original data, it checks the encoded version (the CommR), which during the Proof of Replication was proved to be an encoding of the original data. Since the CommR is a type of merkle tree called a Directed Acyclic Graph (DAG), this can be done with a merkle inclusion proof.
When miners agree to store data for a client, they're required to put down collateral. If they fail a Proof of Spacetime at any point during the contract, they'll be penalized. This is a key part of the incentivization that encourages good behavior amongst all the players in the Filecoin network.
In a Proof of Replication, a storage miner proves that they are storing a physically unique copy, or replica, of the data. Proof of Replication happens just once, at the time the data is first stored by the miner.
Filling sectors and generating the CommD
As the storage miner receives each piece of client data, they place it into a sector. Sectors are the fundamental units of storage in Filecoin, and can contain pieces from multiple deals and clients.
Once a sector is full, a CommD (Commitment of Data, aka UnsealedSectorCID) is produced, representing the root node of all the piece CIDs contained in the sector.
Sealing sectors and producing the CommR
Next, a process called sealing takes place.
During sealing, the sector data (identified by the CommD) is encoded through a sequence of graph and hashing processes to create a unique replica. The root hash of the resulting replica is the CommR (Commitment of Replication, aka SealedSectorCID), which is recorded to the blockchain.
The encoding process is designed to be slow and computationally heavy, making it difficult to spoof. (Note that encoding is not the same as encryption. If you want to store private data, you must encrypt it before adding it to the Filecoin network.)
The CommR offers the proof we need that the miner is storing a physically unique copy of the client's data. If you store the same data with multiple storage miners, or make multiple storage deals for the same data with a single miner, each deal will have a different CommR.
The sealing process also compresses the Proof of Replication using zk-SNARKs to keep the chain smaller so that it can be stored by all members of the Filecoin network for verification purposes. We'll learn more about zk-SNARKs in a future lesson.
Before a system file (e.g. puppy.gif) can be stored on the Filecoin network, it must first be transformed into a Filecoin Piece.
In the first stage of this transformation, the system file is chunked up with UnixFS to create an IPLD DAG (Directed Acyclic Graph). You can learn more about DAGs (a form of merkle tree) in our Decentralized Data Structures tutorial. This IPLD DAG has a payload CID, identical to an IPFS CID, which represents the root of the DAG.
The IPLD DAG is then serialized to a CAR file and bitpadded to make a Filecoin Piece. This piece has a unique piece CID, also known as a CommP (Piece Commitment).
Since payload CIDs and piece CIDs are cryptographic hashes of the data itself, they're unique, with identical CIDs guaranteeing identical content. Identical IPLD DAGs will produce identical payload CIDs and identical pieces will produce identical piece CIDs, no matter who's going to store or retrieve them.
Negotiating a storage deal and transferring data
When a client negotiates a storage deal with a miner, they're hiring them to store a piece of data, which might be a whole or partial file. Miners store these pieces from one or more clients in sectors, the fundamental storage unit used by Filecoin. Sectors come in a variety of sizes, and a client can store data up to the largest sector size per deal. (Learn more about sector sizes and storing large files.)
A piece CID is wrapped with other deal parameters to create a Deal Proposal. The deal CID contains information about the data itself, in the form of the piece CID, the identities of the miner and client, and other important transaction details.
The client sends this deal proposal to a miner, who agrees to store their data. Once the miner has confirmed, the client transfers their data to the miner. Once the miner has the data and verifies that it matches the piece CID noted in the deal proposal, they publish the deal proposal on Filecoin's blockchain, committing both parties to the deal.