diff --git a/docs/about-mina/smart-contracts.mdx b/docs/about-mina/smart-contracts.mdx deleted file mode 100644 index 8b6a65b5e..000000000 --- a/docs/about-mina/smart-contracts.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Smart Contracts (zkApps) ---- - -#### zkApps = Dapps + Privacy + Off-Chain Data + Scalability - -As the world’s lightest blockchain, Mina enables an entirely new category of -applications called zkApps: zero-knowledge applications. zkApps are feature-wise -similar to Dapps on Ethereum, but are superior thanks to three specific -properties: - -Verify the integrity of a piece of data without disclosing what it is. Verify -correct execution of expensive computations. Significant scalability benefits. -These types of applications aren’t necessarily new - in a way both exist as -present day blockchains: ZCash as a zkApp with property 1, and Mina as a zkApp -with property 2. - -A zkApp is also significantly more efficient than a Dapp on Ethereum. In order -for the Ethereum world computer to make a commitment to its users about the -execution of a Dapp, every node and miner on the network has to run the same -computation. This is wildly inefficient. With a zkApp on Mina, the zkApp gets -executed once by its developer, after which all other nodes can just verify the -associated SNARK proof. One can make the same argument for SNARK powered Layer 2 -Dapps on Ethereum, however those Dapps are still encumbered by the limited -throughput of the main chain, whereas a zkApp on Mina benefits from the -scalability potential of the Mina blockchain thanks to its succinct nature. - -In general, a zkApp on Mina has the following workflow: - -- Identify the code to run, open source it if it isn’t already -- Use the code to deploy a SNARK circuit via a function call on Mina -- Source the data to perform the computation on -- Call the function with the relevant data -- Computation runs on chain, similar to a smart contract [ready 6-12 months - after mainnet] -- Attach the SNARK proof returned from the function to a Mina address -- Mina executes transactions based on result of the SNARK proof - -#### What else to add - -- Brief overview, including brief example use cases (non-technical aspects) -- link developers to learn how to write a zkApp or view zkApp developer docs diff --git a/docs/mina-faq.mdx b/docs/mina-faq.mdx deleted file mode 100644 index bb757756c..000000000 --- a/docs/mina-faq.mdx +++ /dev/null @@ -1,85 +0,0 @@ -# FAQ - - - -## General Questions - - - - -### Why did you develop a new protocol? - -The reason for developing a new protocol instead of offering services to other blockchains is because adding SNARKs after the fact to a Layer 1 project is not trivial. Even basic operations need to be optimized for performance inside a SNARK, and existing implementations are not able to be retrofit as such. If we look at hashing functions for example, SHA256 (used by Bitcoin) or Keccak (used by Ethereum) are extremely expensive inside a SNARK circuit, but Poseidon (what Mina uses) is optimized for performance. This and many other technical considerations make it infeasible to easily add recursive SNARKs to existing Layer 1 blockchains, without entirely overhauling the base protocol. - -#### How does Mina verify the current state of the chain without having historical data? How do you audit a transaction if you only keep a proof of the blockchain? - -The average user does not need to know the entire transaction history. For -example, when you make a purchase using a dollar, you also don't need to know -where that dollar came from and how it was spent before arriving in your wallet. -Other blockchains depend on the transaction history to verify that the current -state is valid. Mina is using zk-SNARKs to prove that (see -[this video](https://www.youtube.com/watch?v=eWVGATxEB6M) where co-founder Izaak -Meckler explains Mina's recursive use of zk-SNARKs). This enables Mina to become -the world's lightest blockchain and to always be accessible for all. - -For cases where a user wants to prove the inclusion of past transactions, Mina -has a feature called the receipt chain. Each account has its own receipt chain, -represented in the current state by a hash. When a user sends a transaction from -an account, that transaction modifies the receipt chain of the account, to be -the hash of the previous receipt chain, and the new transaction (a merkle list). -This allows users to prove a particular transaction was sent from their account. - -For programs, Mina uses a different programming paradigm than other chains - -instead of being able to reference past history, you can only reference the -current state. This is akin to a filesystem that allows writing, deleting, and -overwriting data, rather than the “append only” filesystem seen in the usual -blockchain. This is intentional, so that Mina will always be lightweight, and -sustainable - once the proof is available to stand in for the history, storing -the history is more for archival or reference purposes, rather than security or -necessary use. - -The programming paradigm in Mina will be designed to reflect this - right now -Mina has minimal data per account. Programs storing more data will have to pay -some amount for that data, likely when added with something like state rent. - -Clients that do seek to have the full archival history can operate as archive -nodes, to store the full history as well. However, because unlike other -blockchains the full history isn’t necessary for any actions that can be -performed on chain, these are more for data analysis purposes than anything -else. - - -#### Does Mina support shielded transactions, like in Zcash? - -No, Mina does not natively implement privacy features at the moment. However, -privacy is a key consideration for cryptocurrencies, and is also on the -development roadmap. - -#### Can I run the Mina daemon as a service - -See here for information about using launchd or systemd with Mina. - -## SNARKs and Snark Workers - -#### Is generating SNARKs similar to Proof-of-Work (PoW) mining? - -No, they are different in several ways: - -- SNARK work is deterministic, while PoW mining requires randomly calculating - hashes to try and solve a puzzle. There is no luck element in SNARK work — if - a snark worker wants to generate a SNARK of a transaction, they only need to - generate the proof once. This means SNARK work is much less expensive and - environmentally wasteful, as the compute is all spent towards a productive - goal. -- There is no difficulty increase for SNARK work, as there is with PoW mining. - In fact, as SNARK constructions, and proof generation times improve, the - difficulty may actually decrease. -- SNARK work is not directly involved in consensus. Snark workers play no role - in determining the next state of the blockchain. Their role is to simply - generate SNARKs of transactions observed in the network -- As a snark worker, there is no requirement for uptime. PoW miners need to run - their rigs non-stop to ensure they don't miss out on a potential block. Snark - workers can come online and offline as they please — it is more like Uber, - where there will always be work to be done, and nobody needs to say ahead of - time when they want to work. -