Skip to content

Commit

Permalink
fix: on-chain
Browse files Browse the repository at this point in the history
eigmax committed Jul 7, 2024
1 parent 926de2d commit ee4ed91
Showing 6 changed files with 8 additions and 7 deletions.
2 changes: 1 addition & 1 deletion docs/usage/Governance.md
Original file line number Diff line number Diff line change
@@ -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.

2 changes: 1 addition & 1 deletion src/guides/da.md
Original file line number Diff line number Diff line change
@@ -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.



2 changes: 1 addition & 1 deletion src/guides/overview.md
Original file line number Diff line number Diff line change
@@ -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.
4 changes: 2 additions & 2 deletions src/guides/trustless-bridge.md
Original file line number Diff line number Diff line change
@@ -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)
3 changes: 2 additions & 1 deletion src/index.md
Original file line number Diff line number Diff line change
@@ -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

2 changes: 1 addition & 1 deletion src/secret/overview.md
Original file line number Diff line number Diff line change
@@ -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

0 comments on commit ee4ed91

Please sign in to comment.