github/darkfi
1
1
Fork 0
mirror of https://github.com/darkrenaissance/darkfi.git synced 2026-01-09 14:48:08 -05:00
Code Issues Packages Projects Releases Wiki Activity

doc: Minor typo fixes

Browse Source 
Signed-off-by: omahs <73983677+omahs@users.noreply.github.com>
This commit is contained in:
omahs
2024-10-02 09:49:39 +02:00
committed by skoupidi
parent bd63329547
commit e1bc6f904f
5 changed files with 18 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/src/arch/arch.md
View File

@@ -262,5 +262,5 @@ to properly price them for verification fees.
### Documentation
* Create beginner level tutorial to introduce contract developement and tools.
* Create beginner level tutorial to introduce contract development and tools.
* Create a list of outstanding work before mainnet.

6
doc/src/arch/consensus.md
View File

@@ -83,7 +83,7 @@ sum of its block's squared target distances, and the second being the sum of
their squared hash distances. Squared distances are used to disproportionately
favors smaller targets, with the idea being that it will be harder to trigger
a longer reorg between forks. When we compare forks, we first check the first
sum, and if its tied, we use the second as the tie breaker, since we know it
sum, and if it's tied, we use the second as the tie breaker, since we know it
will be statistically unique for each sequence.
The ranking of a fork is always increasing as new blocks are appended.
@@ -163,7 +163,7 @@ Extending the canonical blockchain with a new block proposal:
## Finalization
Based on the rank properties, each node will diverge to the highest ranking
fork, and new fork wil emerge extending that at its tips.
fork, and new fork will emerge extending that at its tips.
A security threshold is set, which refers to the height where the probability
to produce a fork, able to reorg the current best ranking fork reaches zero,
similar to the # of block confirmation used by other PoW based protocols.
@@ -315,7 +315,7 @@ which means it's sufficient to compare $𝐚$ and $𝐛$ directly.
## Proposed Rank
With a PoW mining system, we are guaranteed to always have that the block hash
With a PoW mining system, we are guaranteed to always have the block hash
$h(b) ≤ T(b)$. Since the block hashes $( h(b₁), …, h(bₘ) )$ for a sequence
$( b₁, …, bₘ )$ have the property that $∑ h(bᵢ) ≤ ∑ T(bᵢ)$, as well as being
sufficiently random, we can use them to define our work function.

6
doc/src/arch/dao.md
View File

@@ -5,7 +5,7 @@
There is a scheme called commit-and-reveal, where given an object $x$
(or set of objects), you generate a random blind $b$, and construct the
commitment $C = \textrm{hash}(x, b)$. By publishing $C$, you are
commmitted to the value $x$.
committed to the value $x$.
Secondly, we may wish to publish long lived objects on the blockchain,
which are essentially commitments to several parameters that represent
@@ -184,7 +184,7 @@ the vote is proposed.
## Forking the Global State (with SMT)
Instead of revealing the nullifier, we instead snapshot the the nullifier
Instead of revealing the nullifier, we instead snapshot the nullifier
tree alongside $C$.
The downsides are:
@@ -238,7 +238,7 @@ The proposal is as follows and involves a merkle tree $𝐂$, and a SMT $𝐍$.
For the sake of clarity, we will not detail the storing of the trees themselves.
For $𝐂$, the tree is stored in `db_info`, while $𝐍$ has a full on-disk
representation. Instead the info in this section concerns the auxilliary data
representation. Instead the info in this section concerns the auxiliary data
required for using the trees with snapshotted states.
## DB Merkle Roots

4
doc/src/arch/overview.md
View File

@@ -7,7 +7,7 @@ outline a few key terms that help explain DarkFi.
**Blockchain:** The DarkFi blockchain is based off Proof of Work RandomX
algorithm, paired with Delayed finality. Consensus participating nodes,
called miners, produce and propose new blocks to the network, extending
some fork chain, which once it reaches a finality security thresshold,
some fork chain, which once it reaches a finality security threshold,
can be appended to canonical by all nodes in the network.
**Wallet:** A wallet is a portal to the DarkFi network. It provides
@@ -23,7 +23,7 @@ and P2P task manager [tau](../misc/tau.md).
**ZK smart contracts:** Anonymous applications on DarkFi run on proofs
that enforce an order of operations. We call these zero-knowledge smart
contracts. Anonymous transactions on DarkFi is possible due to the
contracts. Anonymous transactions on DarkFi are possible due to the
interplay of two contracts, mint and burn (see the [sapling payment
scheme](../zkas/examples/sapling.md)). Using the same method, we can
define advanced applications.

18
doc/src/zero2darkfi/darkmap.md
View File

@@ -6,13 +6,13 @@ Suppose you want to build a name registry.
You want this to be:
* resistant to any coercion
* leaving no trace who owns a name
* leaving no trace of who owns a name
Because the users intend to use it for critical things that they like privacy for.
Say naming their wallet address e.g. anon42's wallet address -> 0x696969696969.
Getting a wrong wallet address means, you pay a bad person instead of anon42.
Revealing who owns the name reveals information who might own the wallet.
Revealing who owns the name reveals information on who might own the wallet.
Both are unacceptable to your users.
Upon examination we see backdoor in many solutions.
@@ -25,7 +25,7 @@ Upon examination we see backdoor in many solutions.
An immutable name registry deployed on Darkfi.
* names can be immutable, not even the name registry owner can change the name
* there is no trace who owns the name
* there is no trace of who owns the name
### API: Get
@@ -81,7 +81,7 @@ cd ../ && git clone https://github.com/darkrenaissance/darkmap
## Tool 1: `ZKAS`, `ZKVM`
We want a way for someone to control an account and account to control one name registry.
You could use public key crytography.
You could use public key cryptography.
But in here, we will use ZK to accomplish the same thing for our learning.
In Darkfi, circuits are programmed in `ZKAS` (ZK Assembly) and later run in `ZKVM` for generating proofs.
@@ -100,13 +100,13 @@ Let's see how to run the set_v1.zk by reading `<darkfi>/bin/zkrunner/README.md`.
### Outcome
Good job! Now you have you learned how to prove and run using a ZKAS circuit.
Good job! Now you have learned how to prove and run using a ZKAS circuit.
## Tool 2: WASM contract
In Darkfi, a contract is deployed as a wasm module.
Rust has one of the best wasm support along with C and C++, so Darkmap is implemented in Rust.
In theory, any language that compiles to wasm can be used make a contract.
In theory, any language that compiles to wasm can be used to make a contract.
Let's learn about the contract by reading `<darkmap>/src/entrypoints.rs`.
@@ -117,17 +117,17 @@ FIXME: perhaps more detailed explanation
## Deploying
Currently, the infrastructure for deploying non-native contracts is being worked on.
So Darkmap was tested by modifiying the darkfi validator to deploy it as native contract.
So Darkmap was tested by modifying the darkfi validator to deploy it as native contract.
If you like to try it out, take a look at the [pull request draft](https://codeberg.org/darkrenaissance/darkfi/pulls/170/files#diff-1592d061816d5a4da17e089758e15df75ae1ab963b2288e6d84b8f29b06f7d4f).
In particular:
* `src/consensus/validator.rs`
* `sdk/src/crpyto/*`
* `sdk/src/crypto/*`
## Testing and client implementation
For now, the best place to learn is learn from the darkmap pull request draft or `src/contract/money`.
For now, the best place to learn is to learn from the darkmap pull request draft or `src/contract/money`.
## Notes