diff --git a/docs/usage/Governance.md b/docs/usage/Governance.md index 38bc2c51..adb8f4b2 100644 --- a/docs/usage/Governance.md +++ b/docs/usage/Governance.md @@ -7,7 +7,7 @@ A Governance Proposal can be created by any user who have enough a special ERC20 - **Delegation**. You can delegate the votings to someone (including yourself) without transfering them - **Checkpoints Recording**. To prevent users from cheating, the voting number for a user is determined by the start time of each proposal. So any user can't gain their votings by any actions. The checkpoints are recorded on the chain to implement this function -The proposal should incorporate feedback from the Consensus Check and is accompanied by executable on-chain code. In our test environment, in order to submit an on-chain Governance proposal, a delegate must have a minimum balance of 0.2m `GovernanceToken`. The voting period lasts 1 hour and a majority vote with a 4m `GovernanceToken` yes-vote threshold wins. +The proposal should incorporate feedback from the Consensus Check and is accompanied by executable onchain code. In our test environment, in order to submit an on-chain Governance proposal, a delegate must have a minimum balance of 0.2m `GovernanceToken`. The voting period lasts 1 hour and a majority vote with a 4m `GovernanceToken` yes-vote threshold wins. If a proposal wins, it can be queued by anyone. Another 0.5h delay is need to let people know that the proposal is going to be executed. Then the proposal can be executed, of course, by any one. diff --git a/src/guides/da.md b/src/guides/da.md index 618d50c6..661ee872 100644 --- a/src/guides/da.md +++ b/src/guides/da.md @@ -7,7 +7,7 @@ Data Segmentation: The blockchain data is divided into small pieces or chunks. Random Sampling by Nodes: Nodes in the network randomly select and download only some of these chunks rather than the entire data set. Probabilistic Verification: By analyzing these samples, nodes can probabilistically verify the availability of the entire data set. If the sampled chunks are available and valid, it is highly likely that the rest of the data is also available and valid. -Since we use zkVM to support different L1 for scalalibity, like ETH, Cardano or TON. Some L1s provide cheap on-chain blob storage, and most of them not. Eigen zkVM integrates with some DA solution and enables developers to publish and verify their data. +Since we use zkVM to support different L1 for scalalibity, like ETH, Cardano or TON. Some L1s provide cheap onchain blob storage, and most of them not. Eigen zkVM integrates with some DA solution and enables developers to publish and verify their data. diff --git a/src/guides/overview.md b/src/guides/overview.md index 524215a1..68363390 100644 --- a/src/guides/overview.md +++ b/src/guides/overview.md @@ -9,7 +9,7 @@ Enable the developer to write Rusty circuits * Modular proof system: The first Rust eSTARK implementation, and support eSTARK-to-Groth16/Plonk -Support BLS12381 and BN254 for on-chain verification +Support BLS12381 and BN254 for onchain verification * Continuation and proof composition Allow the program to be split into multiple chunks, and all the chunks are proved parallelly. diff --git a/src/guides/trustless-bridge.md b/src/guides/trustless-bridge.md index 4fd29d2a..08ebede4 100644 --- a/src/guides/trustless-bridge.md +++ b/src/guides/trustless-bridge.md @@ -37,7 +37,7 @@ More details can be found on our [Medium](https://eigenlab.medium.com/ecdsa-vs-e * Deposit on L1: -The user calls the `bridgeAsset` method on L1 smart contract, and deposits an amount of asset into the bridge contract, the `bridgeAsset` inserts a new leaf on the L1 Merkle tree and emits an event of the `bridgeAsset` paramters, the user watches the on-chain events and calculates the Merkle Proof p_1 locally, where: +The user calls the `bridgeAsset` method on L1 smart contract, and deposits an amount of asset into the bridge contract, the `bridgeAsset` inserts a new leaf on the L1 Merkle tree and emits an event of the `bridgeAsset` paramters, the user watches the onchain events and calculates the Merkle Proof p_1 locally, where: ``` Leaf := amount and public key(pk_l2) @@ -64,7 +64,7 @@ In the L2 bridge contract, it does: * Deposit on L2: -The user calls the `bridgeAsset` method on L2 smart contract, and deposits an amount of asset into the bridge contract, the `bridgeAsset` inserts a new leaf on the L2 Merkle tree and emits an event of the `bridgeAsset` paramters, the user watches the on-chain events and calculates the Merkle Proof p_2 locally, where: +The user calls the `bridgeAsset` method on L2 smart contract, and deposits an amount of asset into the bridge contract, the `bridgeAsset` inserts a new leaf on the L2 Merkle tree and emits an event of the `bridgeAsset` paramters, the user watches the onchain events and calculates the Merkle Proof p_2 locally, where: ``` Leaf := amount and public key(pk_l1) diff --git a/src/index.md b/src/index.md index 9934291d..c06e4f08 100644 --- a/src/index.md +++ b/src/index.md @@ -1,7 +1,8 @@ ## Introduction -Eigen Network builds the general-purpose zkVM with native privacy-preserving technology support on its modular proof system. +Eigen Network: A Proof Market To Scale Fully Onchain Applications. +We build the general-purpose zkVM with natively support for fully onchain computation on its modular proof system. ### Source Code diff --git a/src/secret/overview.md b/src/secret/overview.md index 67935c5a..9fd23d94 100644 --- a/src/secret/overview.md +++ b/src/secret/overview.md @@ -45,7 +45,7 @@ EigenSecret imports an alias, so it supports Account Recovery natually. The L2 account(we call it Secret Account) has an account key and a signing key, and all are EdDSA key pair currently and are changing to EcDSA meanwhile. the account key is used to hold the users' asset and the signing key is used to signing the L2 transaction. All the two keys can be upgraded once you found they are compromised. -Once you found the account key leaked, The [migrateAccount](https://0xeigenlabs.github.io/eigen-secret/classes/sdk.SecretSDK.html#migrateAccount) can be used to replace the old, and mark the old as nullifier and insert the new account into SMT on-chain. +Once you found the account key leaked, The [migrateAccount](https://0xeigenlabs.github.io/eigen-secret/classes/sdk.SecretSDK.html#migrateAccount) can be used to replace the old, and mark the old as nullifier and insert the new account into SMT onchain. For signing key upgrade, [updateAccount](https://0xeigenlabs.github.io/eigen-secret/classes/sdk.SecretSDK.html#updateAccount) is provided. The signing key is also used to encrypt the transaction to prevent