maurelian

Nameprep search

Issue

Cannot find a maintained implementation of name prep for the registrar package

Options

1. Use existing libraries:

maurelian

1. How many (non-library) contracts are in the scope?

Just our MerkleTrie contracts. The bulk of it is this Lib_MerkleTrie.sol (https://github.com/ethereum-optimism/optimism/blob/88eb324e8648a1b5edabb8d817d0ccf8631a8bc9/packages/contracts/contracts/libraries/trie/Lib_MerkleTrie.sol). But also this wrapper for it: https://github.com/ethereum-optimism/optimism/blob/88eb324e8648a1b5edabb8d817d0ccf8631a8bc9/packages/contracts/contracts/libraries/trie/Lib_SecureMerkleTrie.sol

And these three libs found here: https://github.com/ethereum-optimism/optimism/blob/88eb324e8648a1b5edabb8d817d0ccf8631a8bc9/packages/contracts/contracts/libraries/utils

import { Lib_BytesUtils } from "./Lib_BytesUtils.sol";
import { Lib_RLPReader } from "./Lib_RLPReader.sol";

maurelian

Checklist used to review this PR to ensure no breaking changes after regenesis. Based on the changeset doc.

1. Unverified contracts

   • Contracts whose source code has not been verified on Etherscan (Kovan, Optimistic Ethereum) will be wiped out along with their storage.
   • NOTE: Please very that you're not calling any unverified contracts.

2. Contracts whose source code has been verified will be recompiled with the standard Solidity compiler. As a result of this:

3. The EXTCODEHASH and CODESIZE of every contract will change.

maurelian

List of key breaking changes to watch for:

1. Unverified contracts:

   1. Contracts whose source code has not been verified on Etherscan (Kovan, Optimistic Ethereum) will be wiped out along with their storage.

2. Contracts whose source code has been verified will be recompiled with the standard Solidity compiler. As a result of this:

maurelian

✅

maurelian

Description of the withdrawal flow

Starting on L2:

• Any account on L2 may call OVM_L2CrossDomainMessenger.sendMessage() with the information for the L1 message (aka xDomainCalldata)
  • (ie. _target, msg.sender, _message)
  • This data is hashed with the messageNonce storage variable, and the hash is store in the sentMessages mapping (this is not actually used AFAIK)
  • The messageNonce is then incremented.
• The OVM_L2CrossDomainMessenger then passes the xDomainCalldata to OVM_L2ToL1MessagePasser.passMessageToL1()
• the xDomainCalldata is hashed with msg.sender (ie. ovmCaller), and written to the sentMessages mapping.

maurelian

Independent Audit of the ENS Registrar

• Section 1 - Overview
• Section 2 - General discussion
  • 2.1 Lack of bounty participation
  • 2.2 Usage of the LLL implementation of the Registry
• Section 3 - Solidity Contracts Analysis
  • 3.1 Unanticipated behavior for unrevealed bids on unowned auctions [medium]

maurelian

Start with these resources

• https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477 - Vitalik
  • Despite this being a ZK focused approach, and only supporting deposit/withdraw/send/receive, it’s nicely laidout as a starting point
• https://ethresear.ch/t/minimal-viable-merged-consensus/5617 - John Adler
  • I think this is the first description of the optimistic model
• https://medium.com/@adlerjohn/the-why-s-of-optimistic-rollup-7c6a22cbb61a - John Adler
• This article focuses a bit less on the mechanics, and more on the beneficial properties.

maurelian

Token	Feature	Known Vulnerabilities	Resources	Examples
ERC20	Allowance	Double withdrawal (front-running)

maurelian

About rust security and auditing

• AUDITING RUST CRYPTO: THE FIRST HOURS

• Review clippy warnings; most of the time these are benign or irrelevant, but they can help spotting red flags.
• Build and run all the unit tests, assess the code coverage and keep note of the un(der)tested component.
• Review the dependencies listed in Cargo.toml and Cargo.lock: Will the latest version be used? (preferable but not always the right choice) Are these established, trustworthy packages? You may use the subcommand cargo-audit (thanks @dues__ for the pointer).
• Look for unsafe code blocks, and evaluate the risk (can an attacker control the input used in these blocks? etc.)
• Look for risky uses of unwrap(), which can cause panics, as opposed to pattern-matched error