chore: merge branch 'main' into prerelease/2.0.0

onchain/rollups/.changeset/fifty-keys-tickle.md → .changeset/fifty-keys-tickle.md

@@ -7,5 +7,5 @@ Modified the `EtherPortal` contract:
 -   Made it support the following interfaces (as in EIP-165):
 
     -   `IERC165`
-    -   `IInputRelay`
+    -   `IPortal`
     -   `IEtherPortal`

onchain/rollups/.changeset/lazy-gorillas-scream.md → .changeset/lazy-gorillas-scream.md

@@ -4,4 +4,8 @@
 
 Modified the `IInputRelay` interface:
 
+-   Renamed it as `IPortal`
+
+-   Moved it to `contracts/portals`
+
 -   Made it inherit from `IERC165`

onchain/rollups/.changeset/lemon-rivers-nail.md → .changeset/lemon-rivers-nail.md

@@ -7,5 +7,5 @@ Modified the `ERC1155BatchPortal` contract:
 -   Made it support the following interfaces (as in EIP-165):
 
     -   `IERC165`
-    -   `IInputRelay`
+    -   `IPortal`
     -   `IERC1155BatchPortal`

onchain/rollups/.changeset/quiet-guests-greet.md → .changeset/quiet-guests-greet.md

@@ -9,4 +9,4 @@ Modified the `ICartesiDAppFactory` interface:
 -   Added the following parameters to its functions and events:
 
     -   `inputBox`
-    -   `inputRelays`
+    -   `portals`

onchain/rollups/.changeset/red-wasps-report.md → .changeset/red-wasps-report.md

@@ -9,7 +9,7 @@ Modified the `CartesiDApp` contract:
 -   Added the following parameters to its constructor:
 
     -   `inputBox`
-    -   `inputRelays`
+    -   `portals`
 
 -   Made it support the following interfaces (as in EIP-165):
 

onchain/rollups/.changeset/rude-scissors-try.md → .changeset/rude-scissors-try.md

@@ -7,5 +7,5 @@ Modified the `ERC1155SinglePortal` contract:
 -   Made it support the following interfaces (as in EIP-165):
 
     -   `IERC165`
-    -   `IInputRelay`
+    -   `IPortal`
     -   `IERC1155SinglePortal`

onchain/rollups/.changeset/seven-teachers-behave.md → .changeset/seven-teachers-behave.md

@@ -12,5 +12,5 @@ Removed:
 -   the `IAuthorityHistoryPairFactory` interface.
 -   the `OutputEncoding` library.
 -   the `LibInput` library.
--   the `ApplicationAddressRelay` contract.
--   the `IApplicationAddressRelay` interface.
+-   the `DAppAddressRelay` contract.
+-   the `IDAppAddressRelay` interface.

onchain/rollups/.changeset/silly-islands-end.md → .changeset/silly-islands-end.md

@@ -36,7 +36,7 @@ Modified the `ICartesiDApp` interface:
 
 -   Added a `getInputBox` function.
 
--   Added a `getInputRelays` function.
+-   Added a `getPortals` function.
 
 -   Added an `InputIndexOutOfRange` error.
 

onchain/rollups/.changeset/smooth-ducks-trade.md → .changeset/smooth-ducks-trade.md

@@ -4,7 +4,11 @@
 
 Modified the `InputRelay` contract:
 
+-   Renamed it as `Portal`
+
+-   Moved it to `contracts/portals`
+
 -   Made it support the following interfaces (as in EIP-165):
 
     -   `IERC165`
-    -   `IInputRelay`
+    -   `IPortal`

onchain/rollups/.changeset/two-mails-marry.md → .changeset/two-mails-marry.md

@@ -7,5 +7,5 @@ Modified the `ERC20Portal` contract:
 -   Made it support the following interfaces (as in EIP-165):
 
     -   `IERC165`
-    -   `IInputRelay`
+    -   `IPortal`
     -   `IERC20Portal`

onchain/rollups/.changeset/wise-owls-push.md → .changeset/wise-owls-push.md

@@ -7,5 +7,5 @@ Modified the `ERC721Portal` contract:
 -   Made it support the following interfaces (as in EIP-165):
 
     -   `IERC165`
-    -   `IInputRelay`
+    -   `IPortal`
     -   `IERC721Portal`

.github/ISSUE_TEMPLATE/update-dependencies.md

@@ -16,5 +16,5 @@ Are there any clear downsides? (requires refactoring, bugs were introduced, etc)
 
 - [ ] Update major versions in `packages.json`.
 - [ ] If an update requires major work, create the corresponding issue.
-- [ ] Update the dependencies in `yarn.lock`.
+- [ ] Update the dependencies in `pnpm-lock.yaml`.
 - [ ] Verify whether everything is working as expected.

.github/workflows/check-code-format.yml

@@ -1,27 +1,14 @@
 name: Check code format
 
-on:
-  push:
-    paths:
-      - '.github/workflows/check-code-format.yml'
-      - 'onchain/rollups/**'
+on: [push]
 
 jobs:
   check-code-format:
     runs-on: ubuntu-latest
-    defaults:
-      run:
-        working-directory: onchain/rollups
-
     steps:
       - uses: actions/checkout@v4
 
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 18
-
-      - name: Install dependencies
-        run: yarn install
+      - uses: ./.github/workflows/setup
 
       - name: Check code format
-        run: yarn fmt:check
+        run: pnpm fmt:check

.github/workflows/docs.yml

@@ -0,0 +1,36 @@
+name: Deploy documentation to GitHub Pages
+
+on:
+  push:
+    branches: ["main"]
+
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          submodules: recursive
+
+      - uses: ./.github/workflows/setup
+
+      - name: Generate documentation
+        run: forge doc -b
+
+      - uses: actions/configure-pages@v4
+
+      - uses: actions/upload-pages-artifact@v3
+        with:
+          path: docs/book
+
+      - id: deployment
+        uses: actions/deploy-pages@v4

.github/workflows/release.yml

@@ -16,9 +16,6 @@ jobs:
     outputs:
       published: ${{ steps.changeset.outputs.published }}
       version: ${{ steps.get_version.outputs.version }}
-    defaults:
-      run:
-        working-directory: onchain/rollups
 
     steps:
       - uses: actions/checkout@v4
@@ -30,21 +27,15 @@ jobs:
           git config user.name rollups-contracts-bot
           git config user.email [email protected]
 
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 18
-
-      - name: Install Node dependencies
-        run: yarn install
+      - uses: ./.github/workflows/setup
 
       - name: Create release PR or publish packages to npmjs.com
         uses: changesets/action@f13b1baaa620fde937751f5d2c3572b9da32af23
         id: changeset
         with:
           setupGitUser: false
           commit: "chore: version packages"
-          publish: yarn changeset publish
-          cwd: onchain/rollups
+          publish: pnpm changeset publish
         env:
           GITHUB_TOKEN: ${{ secrets.BOT_TOKEN }}
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
@@ -58,27 +49,16 @@ jobs:
     needs: version_or_publish
     if: ${{ needs.version_or_publish.outputs.published == 'true' }}
     runs-on: ubuntu-latest
-    defaults:
-      run:
-        working-directory: onchain/rollups
-
     steps:
       - uses: actions/checkout@v4
         with:
           submodules: recursive
 
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 18
-
-      - uses: foundry-rs/foundry-toolchain@v1
+      - uses: ./.github/workflows/setup
 
       - name: Install Python dependencies
         run: pip install yq
 
-      - name: Install Node dependencies
-        run: yarn install
-
       - name: Generate Rust bindings
         run: |
           forge bind \
@@ -88,13 +68,13 @@ jobs:
           VERSION: ${{ needs.version_or_publish.outputs.version }}
 
       - name: Edit Rust package manifest
-        working-directory: onchain/rollups/out/bindings
+        working-directory: out/bindings
         run: |
           tomlq -ti '.package.license = "Apache-2.0"' Cargo.toml
           tomlq -ti '.package.description = "Rust bindings for Cartesi Rollups smart contracts"' Cargo.toml
 
       - name: Publish Rust package to crates.io
-        working-directory: onchain/rollups/out/bindings
+        working-directory: out/bindings
         run: cargo publish
         env:
           CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }}

.github/workflows/setup/action.yml

@@ -0,0 +1,22 @@
+name: Install dependencies
+
+on:
+  workflow_call:
+
+runs:
+  using: 'composite'
+  steps:
+    - uses: pnpm/action-setup@v3
+      with:
+        version: 8
+
+    - uses: actions/setup-node@v4
+      with:
+        node-version: 18
+        cache: 'pnpm'
+
+    - name: Install Node packages
+      shell: bash
+      run: pnpm i
+
+    - uses: foundry-rs/foundry-toolchain@v1

.github/workflows/test.yml

@@ -15,29 +15,18 @@ concurrency:
 jobs:
   test:
     runs-on: ubuntu-latest
-    defaults:
-      run:
-        working-directory: onchain/rollups
-
     steps:
       - uses: actions/checkout@v4
         with:
           submodules: recursive
 
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 18
-
-      - uses: foundry-rs/foundry-toolchain@v1
-
-      - name: Install dependencies
-        run: yarn install
+      - uses: ./.github/workflows/setup
 
       - name: Generate proofs
-        run: yarn proofs:setup
+        run: pnpm proofs:setup
 
       - name: Run tests
-        run: yarn test
+        run: pnpm test
 
       - name: Upload signatures
         run: forge selectors upload --all

.gitignore

@@ -1,5 +1,18 @@
-node_modules
-.vscode
-.env
 .DS_Store
-**/.idea/
+.env
+.node*
+.vscode
+/abi
+/artifacts
+/cache
+/contracts.json
+/coverage*
+/deployments/*/solcInputs/*.json
+/deployments/localhost
+/dist
+/docs
+/export/artifacts
+/forge-cache
+/node_modules
+/out
+/src/types

.gitmodules

@@ -1,9 +1,3 @@
-[submodule "onchain/rollups-arbitration/lib/forge-std"]
-	path = onchain/rollups-arbitration/lib/forge-std
-	url = https://github.com/foundry-rs/forge-std
-[submodule "onchain/rollups-arbitration/lib/solidity-util"]
-	path = onchain/rollups-arbitration/lib/solidity-util
-	url = https://github.com/cartesi/solidity-util
-[submodule "onchain/rollups/lib/forge-std"]
-	path = onchain/rollups/lib/forge-std
+[submodule "forge-std"]
+	path = lib/forge-std
 	url = https://github.com/foundry-rs/forge-std

CODEOWNERS

@@ -1,3 +1,3 @@
 CODEOWNERS @guidanoli
 /.github/workflows/ @guidanoli
-/onchain/rollups/package.json @pedroargento
+/package.json @pedroargento

CONTRACTS.md

@@ -77,13 +77,13 @@ The Application Factory allows anyone to deploy `Application` contracts with a s
 
 ### Portals
 
-Portals, as the name suggests, are used to safely teleport assets from the base layer to the execution layer. It works in the following way. First, for some types of assets, the user has to allow the portal to deduct the asset(s) from their account. Second, the user tells the portal to transfer the asset(s) from their account to some application's account. The portal then adds an input to the application's input box to inform the machine of the transfer that just took place in the base layer. Finally, the off-chain machine is made aware of the transfer through the input sent by the portal. Note that the machine must know the address of the portal beforehand in order to validate such input.
+Portals, as the name suggests, are used to safely teleport assets from the base layer to the execution layer. It works in the following way. First, for some types of assets, the user has to allow the portal to deduct the asset(s) from their account. Second, the user tells the portal to transfer the asset(s) from their account to the application's account. The portal then adds an input to the application's input box to inform the machine of the transfer that just took place in the base layer. Finally, the off-chain machine is made aware of the transfer through the input sent by the portal. Note that the machine must know the address of the portal beforehand in order to validate such input.
 
 The application developer can choose to do whatever they want with this information. For example, they might choose to create a wallet for each user in the execution layer, where assets can be managed at a much lower cost through inputs that are understood by the Linux logic. In this sense, one could think of the application contract as a wallet, owned by the off-chain machine. Anyone can deposit assets there but only the application—through vouchers—can decide on withdrawals.
 
 The withdrawal process is quite simple from the user's perspective. Typically, the user would first send an input to the application requesting the withdrawal, which would then get processed and interpreted off-chain. If all goes well, the machine should generate a voucher that, once executed, transfers the asset(s) to the rightful recipient.
 
-Currently, we support the following types of assets:
+Currently, the following types of assets are supported:
 
 - [Ether](https://ethereum.org/en/eth/) (ETH)
 - [ERC-20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) (Fungible tokens)
@@ -114,7 +114,7 @@ As an example, the deposit of 100 Wei (of Ether) sent by address `0xf39fd6e51aad
 
 Vouchers allow applications in the execution layer to interact with contracts in the base layer through message calls. They are emitted by the off-chain machine, and can be executed by anyone in the base layer. Each voucher is composed of a destination address, a value, and a payload. In the case of vouchers destined to Solidity contracts, the payload generally encodes a function call. Moreover, the value field denotes the amount of Wei to be passed along the message call to the destination, which can be used for Ether withdrawals and for payable function calls.
 
-A voucher can only be executed once the application's consensus accepts a claim containing it. They can be executed in any order. Although the application contract is indifferent to the content of the voucher being executed, it enforces some sanity checks before allowing its execution. First, it checks whether the voucher has been successfully executed already. Second, it ensures that the voucher has been emitted by the off-chain machine, by requiring a validity proof.
+A voucher can only be executed once the application's consensus accepts a claim containing it. They can be executed in any order. Although the application contract is indifferent to the content of the voucher being executed, it enforces some sanity checks before allowing its execution. First, it makes sure the voucher hasn't been executed yet. Second, it ensures that the voucher has been emitted by the off-chain machine by checking the provided validity proof.
 
 Because of their generality, vouchers can be used in a wide range of applications: from withdrawing funds to providing liquidity in DeFi protocols. Typically, applications use vouchers to withdraw assets. Below, we show how vouchers can be used to withdraw several types of assets. You can find more information about a particular function by clicking on the :page_facing_up: emoji near it.