## Introduction to flowcoin

Flowcoin (abbreviated as: FLW) is a fully open-source and fully open distributed main network developed on the basis of IPFS. Everyone can develop related plug-ins to achieve more applications, and have a decentralized, deduplicated, fragmented, faster transmission speed and more secure blockchain public chain, which is used as an incentive layer to reward the contribution traffic. digital wave.

## Flowcoin algorithm

Proof of reproduction" (PoRep) is a new type of storage certificate. It allows the server (certifier P) to convince the user
(verifier V) that some data D has been copied to its only dedicated physical storage.
Our solution is an interactive protocol. Proofer P: (a) promise to store n different
copies of data D (independent physical copies), and then (b) convince the verifier V
through a challenge / response protocol that P has indeed stored each copy. As far as
we know, PoRep improves the PDP and PoR schemes, preventing witch attacks, outsourcing
attacks, and generation attacks.

Please note that for the formal definition of the proof of copy and the description
of its attributes and its in-depth research, we recommend readers to read another academic
report of the protocol laboratory.

The spatio- temporal certificateThe PoRep scheme enables an effective prover P
to convince the verifier V that an independent physical copy R of the data D that is
exclusive to P has been stored on P. PoRep protocol is characterized by a tuple of polynomial
time algorithms: (Setup, Prove, Verify).

PoRep.Setup (1λ, D)→R, Sp, Sv, where Sp and Sv are the setting variables of the
characteristic schemes of P and V, and λ is a safety parameter. PoRep.Setup is used to
generate replica R, and give P and V the necessary information to run PoRep.Prove and
PoRep.Verify. Some solutions may require a prover or an interactive third party to calculate
PoRep.Setup.

PoRep.Verify (Sp,R, C)→πc, where C is the verification issued certifier V, πc
prove access to a copy of the particular prover generated for the data D R. PoRep.Prove
by the P (prover) to V (verifier) run generated πc.

PoRep.Verify (Sv,c, πc) →{0,1}, used to check whether the proof is correct. PoRep.Verify
run B by the V and to convince V: P has stored R.

The spatio-temporal certificate scheme allows users to detect whether the storage vendor
has stored outsourced data during the challenge. How can we use the PoS scheme to prove
that the data is stored in a short time? A natural answer to this question is to ask
the user to repeatedly (as per minute) issued a challenge to the storage vendor. However,
the communication complexity required for each interaction will become a bottleneck for
systems like Flowcoin, because storage providers will also be required to submit their
proof to the blockchain network.

To answer this question, we introduce a new proof, the spatio-temporal cetificate, in
which the verifier can check whe ther the prover has stored his / her outsourced data
over a period of time. Thus the requirements for the prover is (1) generating a proof
storage order (here copy proof) to as (2) performs a recursive method to detemine the
time to generate short demonstrable.

Definition 3.2 (proof of spatio-temporal) PoSt scheme enables the effective prover
P to convince the verifier V: within a period of time t P has stored some data D. PoSt
protocol is characterized by a tuple of polynomial time algorithms (Setup, Prove, Verify)

PoSt.Setup (1λ, D)→Sp, Sv, where Sp and Sv are the setting variables of the characteristic
schemes ofP and V, and λ is a safety parameter. PoSt.Setup is used to give P and V the
necessary information to run PoStProve. Some solutions mayrequire a prover or an interactive
third party to calculate PoSt.Setup.

PoStProve (Sp, D, c, t)→πc, where C is the random verification issued by the verifier
V, and πc is the proof that the prover has access to the data D for a period of time.
PoStProve is run by P (certifier) for V (verifier) to generate πc.

PoStVenify (Sv, c,t, πc) →{0,1}, used to check whether the proof is correct. PoSt.Verify
is run by V and convinces V that P has stored t for a period of time.

We are interested in the application construction of PoRep and PoSt online systems, rather
than relying on hardware or parties. We give a PoRep system architecture (see "Seal-based
replication proof" in the copy proof academic report for details), which requires a very
slow sequential calculation to seal during the Setup process to generate a copy. PoRep
and PoSt protocol sketch given in Figure 4, and the proof of PoSt's underlying mechanism
is shown in Figure 3.

Building encrypted blocks

Anti-collision hash: We use an anti-collision hash function: CRH: {0,1} *→{0,1}0(N).
We also use an anti-collision hash function MerkleCRH, which splits the string into multiple
part construct a binary tree and apply CRH recursively, and then output the root.

zk- SNARKS: The actual facts of our PoRep and Post depend on the concise non-interactive
knowledge theory (zk -SNARKs) with zero-knowledge proofs [6, 7, 8]. Because zk-SNARKs
are concise, the proof is short and easy to verify. More formally, let L be the NP language
and C is the decision circuit of L The trusted party performs the secondary setup phase
and generates two public keys: the proof key pk and the verification key wk. Prove key
pk make any (untrusted) of the prover can produce proof that π for examples of her choice
x，x∈L. The non-interactive proof π is zero knowledge and knowledge proof. Anyone can
verify the proof π using the verification key V. In particular zk-SNARK publicdy verifiable
proof: Anyone can verify π，without interacting with the prover generates π. Prove that
π has a constant size in linear time in |x|.

For the process of zk-SNARKs tuple satisfies polynomial time algorithm: (KeyGen, Prove,
Verify)

KeyGen (1λ,C) - →(pk, vk), input safety parameter λ and circuit C, KeyGen generates
probability samples pk and wk. These two keys are issued as public keys and can be used
to prove / verify membership in Lc.

Prove (pk, x, w)→π, input the witness w declared by pk, x and NP, the prover Prove output
a non-interactive proof for the statementx∈Lc.

Verify (vk,xπ)→{0,1}, inputvk, x and proof π, ifx∈Lc, the verifier verifies 1.

We recommend that interested readers refer to [6] [7] [8] for the official introduction
and examples of the zk- SNARK system. In generally, these systems require a trusted party
to run KeyGen operations. Innovative scalable computing system integrity and privacy
(SCIP) [9] shows a promising direction under the premise of the above assumptions of
trust to avoid this first step.

Sealing operation

The role of the sealing operation is (1) by requiring the prover to store a pseudo-random
arrangement D unique to their public key, forcing the replica to become a physically
independent copy, so that promising to store n replicas will result in n dedicated space
for independent copies (hence the storage size of replicas is n times), and (2) Forced
generation of copies during PoRep.Setup will actually take more time than expected to
respond to challenges. A more formal definition of sealing operations. The above operations
can be implemented with SealAES- 256, and τ makes SealAES- 256 take 10-100 times longer
than the honest challenge verification proof sequence. Please note that choosing τ is
extremely important because running Seal BC τ will undoubtedly take more time than running
Prove with random access ℛ.

Sealing operation

This chapter describes the architecture of the PoRep protocol and includes a simple
protocol sketch in Figure 4. Implementation and optimization details are omitted.

Create a copy. The Setup algorithm generates a copy through the sealing operation
and provides proof. The prover generates a copy and output it (excluding ℛ) to the verifier.

Proof storage: The Prove algorithm generates a proof of storage for copies. The
prover receives a random challenge C from the verifier, and asks to confirm a specific
leaf in the Merkle tree with rt as the root ℛ; the prover generates a knowledge proof
about ℛ, Merkle path to rt proof.

Proof of verification: The Verify algorithm checks the validity of the stored
proof of the Merkle tree root and the original data hash that copy given. Proofs can
be verified publicly: the nodes that maintain the decentralized system ledger and customers
interested in specific data can verify these proofs.

## Massive amounts of storage sit unused in data centers and hard drives around the world.

### Earn Flowcoin for hosting files

Put your unused storage to work by becoming a Flowcoin miner. Use the Flowcoin mining software to get paid for fulfilling storage requests and hosting files on the global Flowcoin market.

### Exchange Flowcoin for USD, BTC, ETH and more

Flowcoin will be traded on a number of exchanges and supported by multiple cryptocurrency wallets, allowing you to easily exchange Flowcoin for other currencies like US Dollars, Bitcoin and Ether.

## New Blockchain, New Breakthroughs

## A Decentralized Market for Storage

### The Flowcoin network achieves staggering economies of scale by allowing anyone worldwide to participate as storage providers.

It also makes storage resemble a commodity or utility by decoupling hard-drive space from additional services. On this robust global market the price of storage will be driven by supply and demand, not corporate pricing departments, and miners will compete on factors like reputation for reliability as well as price.

## Ready, get set, mine Flowcoin

Flowcoin is under active development and Flowcoin node software is free and and open source. Anyone can choose to run Flowcoin nodes and Testnet and Mainnet will be open to the public for anyone to join and mine.

If you’re a miner and would like to help our team with some testing after our Testnet launch, please sign up for our Miner Mailing List.