iden3 / contracts Goto Github PK

Adding a revocation-key-only that allows at any moment to set the relayer to 0x0

• The relayer can be set to 0x0 by calling a revoke() method
• The relayer key can be changed by the recovery key
• If the relayer key is 0x0 is not possible to perform a forward call

Hi,
I can not find the implementation of the poseidon function in Poseidon.sol,how can I implement it?

library PoseidonUnit1L {
function poseidon(uint256[1] calldata) public pure returns (uint256) {}
}

library PoseidonUnit2L {
function poseidon(uint256[2] calldata) public pure returns (uint256) {}
}
....

Thanks！

Hi,

I saw your project on reddit; we are also creating interfaces to allow for identifiers on chain and have published a PR on the ethereum github here

Maybe you will find it useful or have critiques to give?

Thank you,
James

• Check https://github.com/aragon/aragonOS/blob/a56234e3c0265878d5f105c6be2b81f2108f57d6/contracts/common/UnstructuredStorage.sol
• Use keccak("iden3.core.xxx") for slot assigments

The stored block number is read during the smart contract call, which happens before the block is forged, so the block number ends up being the block number where the transaction happens - 1.

• Document code
• Add code coverage

BabyJub Signatures are 64 bytes. The following lines need to be modified to use bytes64 sig:
https://github.com/iden3/contracts/blob/feature/idstate/contracts/State.sol#L54
https://github.com/iden3/contracts/blob/feature/idstate/contracts/State.sol#L66

From a read through of some of the contracts I've seen that iden3 is using a concept similar to EIP1077 Executable Signed Messages as well as some key management stuff that looks (on the surface) similar to what's been proposed in ERC 725.

Could you explain if iden3 will be ERC725 compatible? If not, what are the trade-offs with doing it the iden3 way? What are the similarities?

depends on #21

When using npx hardhat compile --verbose in a hardhat repo that uses IState I get:

  hardhat:core:compilation-job File '/Users/antoineestienne/GithubRepositories/NexeraID/node_modules/.pnpm/@[email protected]/node_modules/@iden3/contracts/interfaces/IState.sol' will be compiled with version '0.8.16' +0ms
  hardhat:core:hre Running task compile:solidity:handle-compilation-jobs-failures +0ms
  hardhat:core:hre Running task compile:solidity:filter-compilation-jobs +0ms
  hardhat:core:tasks:compile force flag enabled, not filtering +6ms
  hardhat:core:hre Running task compile:solidity:merge-compilation-jobs +0ms
  hardhat:core:hre Running task compile:solidity:compile-jobs +3ms
  hardhat:core:hre Running compile:solidity:compile-jobs's super +0ms
  hardhat:core:tasks:compile Compiling 1 jobs +3ms
  hardhat:core:hre Running task compile:solidity:compile-job +1ms
  hardhat:core:tasks:compile Compiling job with version '0.8.16' +1ms
  hardhat:core:hre Running task compile:solidity:get-compiler-input +0ms
  hardhat:core:hre Running compile:solidity:get-compiler-input's super +0ms
  hardhat:core:hre Running task compile:solidity:compile +0ms
  hardhat:core:hre Running compile:solidity:compile's super +1ms
  hardhat:core:hre Running task compile:solidity:solc:compile +0ms
  hardhat:core:hre Running task compile:solidity:solc:get-build +0ms
  hardhat:core:tasks:compile Native solc binary doesn't work, using solcjs instead. Try running npx hardhat clean --global +3ms
  hardhat:core:hre Running task compile:solidity:log:run-compiler-start +2ms
  hardhat:core:hre Running task compile:solidity:solcjs:run +0ms
  hardhat:core:hre Running task compile:solidity:log:run-compiler-end +2s
  hardhat:core:hre Running compile:solidity:compile's super +2ms
  hardhat:core:hre Running task compile:solidity:solc:compile +0ms
  hardhat:core:hre Running task compile:solidity:solc:get-build +0ms
  hardhat:core:tasks:compile Native solc binary doesn't work, using solcjs instead. Try running npx hardhat clean --global +2s
  hardhat:core:hre Running task compile:solidity:log:run-compiler-start +2ms
  hardhat:core:hre Running task compile:solidity:solcjs:run +0ms
  hardhat:core:hre Running task compile:solidity:log:run-compiler-end +23ms
An unexpected error occurred:

Error: Failed to compile modified contracts for namespaced storage:

TypeError: Array with zero length specified.
  --> @iden3/contracts/interfaces/IState.sol:59:17:
   |
59 |         uint256[MAX_SMT_DEPTH] siblings;
   |                 ^^^^^^^^^^^^^



Please report this at https://zpl.in/upgrades/report. If possible, include the source code for the contracts mentioned in the errors above.

This is how it is used in contract:
import {StateV2} from "@iden3/contracts/state/StateV2.sol";

Openzeppelin proposes a way to make proxies transparent by forwarding or not the messages by their sender in the internal proxy calls.

This fits very well with the current recovery address method used.

https://blog.zeppelinos.org/the-transparent-proxy-pattern/

I deploy the iden3 protocol on go-ethereum 1.12.0, and execute the transitState in State.sol (via polygonid js-sdk), "No multiple set in the same block" is triggered.

This error does not trigger on polygon mumbai and go-ethereum version on 1.10.x

Then I come across the following fix in the go-ethereum 1.12.0 https://github.com/ethereum/go-ethereum/pull/24363/files, which changes the block.number from PendingBlockNumber to LatestBlockNumber.

I have modified the code from

prevStateInfo.createdAtBlock != block.number,

to

prevStateInfo.createdAtBlock != (block.number + 1),

And it working fine.

My understand the current IDEN3 protocol has been deployed on Polygon networks. Not sure if this has been deployed in Ethereum.

In the current phase ( https://github.com/iden3/contracts/tree/feature/ph-1 ) we are using BabyJubJub signature verification onchain, but:

• As BabyJubJub ECC has no precompiled version in EVM, the onchain operations with this curve are very expensive
• For the next phase we need to research about using a zkSnark to prove the ownership of the sk instead of verifying the signature onchain
• Appart from the sk verification, we need to verify a MerkleTree proof --> this is also a lot of onchain computation

So, in the current phase we use the BabyJubJub EDDSA signature verification onchain, but for the next phase this together with other verifications will be done through a zkProof, where the computation will be done offchain, and only onchain the verification of the pairings of the Groth16.

• https://github.com/iden3/circomlib/blob/master/src/poseidon_gencontract.js