CI, lint, license

.github/dependabot.yml

@@ -0,0 +1,27 @@
+# Copyright (C) 2024, Ava Labs, Inc. All rights reserved.
+# See the file LICENSE for licensing terms.
+
+# To get started with Dependabot version updates, you'll need to specify which
+# package ecosystems to update and where the package manifests are located.
+# Please see the documentation for all configuration options:
+# https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates
+
+version: 2
+updates:
+  - package-ecosystem: "gomod" # See documentation for possible values
+    directory: "/" # Location of package manifests
+    schedule:
+      interval: "daily"
+    ignore:
+      # Update go-ethereum only via subnet-evm or avalanchego
+      - dependency-name: "github.com/ethereum/go-ethereum"
+      # Avalanchego is updated to stay compatible with subnet-evm
+      - dependency-name: "github.com/ava-labs/avalanchego"
+  - package-ecosystem: "gitsubmodule"
+    directory: "/"
+    schedule:
+      interval: "daily"
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "daily"

.github/workflows/abi_bindings_checker.yml

@@ -0,0 +1,46 @@
+name: ABI Go Bindings Checker
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - "**"
+
+jobs:
+  abi_binding:
+    name: abi_binding
+    runs-on: ubuntu-22.04
+
+    steps:
+      - name: Checkout the repository
+        uses: actions/checkout@v4
+        with:
+          submodules: recursive
+
+      - name: Set Go version
+        run: |
+          source ./scripts/versions.sh
+          echo GO_VERSION=$GO_VERSION >> $GITHUB_ENV
+
+      - name: Setup Go
+        uses: actions/setup-go@v5
+        with:
+          go-version: ${{ env.GO_VERSION }}
+
+      - name: Install Foundry
+        run: ./scripts/install_foundry.sh
+
+      - name: Generate ABI Go bindings
+        run: |
+          export PATH=$PATH:$HOME/.foundry/bin
+          export GOPATH=$HOME/go
+          export PATH="$PATH:$GOPATH/bin"
+          ./scripts/abi_bindings.sh
+
+      - name: Print diff
+        run: git --no-pager diff -- abi-bindings/**.go
+
+      - name: Fail if diff exists
+        run: git --no-pager diff --quiet -- abi-bindings/**.go

.github/workflows/gomod_check.yml

@@ -0,0 +1,31 @@
+name: go.mod Check
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - "**"
+
+jobs:
+  gomod_check:
+    name: Check go.mod
+    runs-on: ubuntu-22ß.04
+
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          submodules: recursive
+
+      - run: |
+          source ./scripts/versions.sh
+          echo GO_VERSION=$GO_VERSION >> $GITHUB_ENV
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: ${{ env.GO_VERSION }}
+
+      - run: go mod tidy
+      - run: git --no-pager diff -- go.mod go.sum # This prints the diff
+      - run: git --no-pager diff --quiet -- go.mod go.sum # This errors if there is a diff

.github/workflows/lint.yml

@@ -0,0 +1,43 @@
+name: Lint
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - "**"
+
+jobs:
+  solhint:
+    runs-on: ubuntu-22.04
+    steps:
+      - name: Checkout repository and submodules
+        uses: actions/checkout@v4
+        with:
+          submodules: recursive
+
+      - name: Install solhint
+        run: |
+          npm install solhint -g
+          solhint --version
+
+      - name: Run Lint
+        run: ./scripts/lint.sh --sol-lint
+
+  format-solidity:
+    runs-on: ubuntu-22.04
+    timeout-minutes: 10
+    steps:
+      - name: Checkout repository and submodules
+        uses: actions/checkout@v4
+        with:
+          submodules: recursive
+
+      - name: Install Foundry
+        run: ./scripts/install_foundry.sh
+
+      - name: Check Solidity Formatting
+        run: |
+          export PATH=$PATH:$HOME/.foundry/bin
+          ./scripts/lint.sh --sol-format-check

.github/workflows/test.yml

@@ -0,0 +1,57 @@
+name: Tests
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - "**"
+
+jobs:
+  solidity-unit-tests:
+    runs-on: ubuntu-22.04
+    timeout-minutes: 10
+    steps:
+      - name: Checkout repository and submodules
+        uses: actions/checkout@v4
+        with:
+          submodules: recursive
+
+      - name: Install Foundry
+        run: ./scripts/install_foundry.sh
+
+      - name: Run unit tests
+        run: |
+          export PATH=$PATH:$HOME/.foundry/bin
+          cd contracts/
+          forge test -vvv
+
+  e2e_tests:
+    name: e2e_tests
+    runs-on: ubuntu-20.04
+    steps:
+      - name: Checkout repositories and submodules
+        uses: actions/checkout@v4
+        with:
+          submodules: recursive
+
+      - name: Set Go version
+        run: |
+          source ./scripts/versions.sh
+          echo GO_VERSION=$GO_VERSION >> $GITHUB_ENV
+
+      - name: Setup Go
+        uses: actions/setup-go@v5
+        with:
+          go-version: ${{ env.GO_VERSION }}
+
+      - name: Install Foundry
+        run: ./scripts/install_foundry.sh
+
+      - name: Run E2E Tests
+        # Forge installs to BASE_DIR, but updates the PATH definition in $HOME/.bashrc
+        run: |
+          export PATH=$PATH:$HOME/.foundry/bin
+          export PATH="$PATH:$GOPATH/bin"
+          ./scripts/e2e_test.sh

.golangci.yml

@@ -0,0 +1,31 @@
+# This file configures github.com/golangci/golangci-lint.
+
+run:
+  timeout: 3m
+  tests: true
+  # skip auto-generated files.
+  skip-dirs:
+    - "abi-bindings/go"
+  skip-files:
+    - ".*mock.*"
+
+issues:
+  # Maximum count of issues with the same text. Set to 0 to disable. Default is 3.
+  max-same-issues: 0
+
+linters:
+  disable-all: true
+  enable:
+    - goimports
+    - gosimple
+    - govet
+    - ineffassign
+    - misspell
+    - unconvert
+    - unused
+    - whitespace
+    - lll
+
+linters-settings:
+  gofmt:
+    simplify: true

LICENSE

@@ -0,0 +1,66 @@
+Copyright (C) 2024, Ava Labs, Inc. All rights reserved.
+
+Ecosystem License
+Version: 1.1
+
+Subject to the terms herein, Ava Labs, Inc. (**“Ava Labs”**) hereby grants you
+a limited, royalty-free, worldwide, non-sublicensable, non-transferable,
+non-exclusive license to use, copy, modify, create derivative works based on,
+and redistribute the Software, in source code, binary, or any other form,
+including any modifications or derivative works of the Software (collectively,
+**“Licensed Software”**), in each case subject to this Ecosystem License
+(**“License”**).
+
+This License applies to all copies, modifications, derivative works, and any
+other form or usage of the Licensed Software. You will include and display
+this License, without modification, with all uses of the Licensed Software,
+regardless of form.
+
+You will use the Licensed Software solely (i) in connection with the Avalanche
+Public Blockchain platform, having a NetworkID of 1 (Mainnet) or 5 (Fuji), and
+associated blockchains, comprised exclusively of the Avalanche X-Chain,
+C-Chain, P-Chain and any subnets linked to the P-Chain (“Avalanche Authorized
+Platform”) or (ii) for non-production, testing or research purposes within the
+Avalanche ecosystem, in each case, without any commercial application
+(“Non-Commercial Use”); provided that this License does not permit use of the
+Licensed Software in connection with (a) any forks of the Avalanche Authorized
+Platform or (b) in any manner not operationally connected to the Avalanche
+Authorized Platform other than, for the avoidance of doubt, the limited
+exception for Non-Commercial Use. Ava Labs may publicly announce changes or
+additions to the Avalanche Authorized Platform, which may expand or modify
+usage of the Licensed Software. Upon such announcement, the Avalanche
+Authorized Platform will be deemed to be the then-current iteration of such
+platform.
+
+You hereby acknowledge and agree to the terms set forth at
+www.avalabs.org/important-notice.
+
+If you use the Licensed Software in violation of this License, this License
+will automatically terminate and Ava Labs reserves all rights to seek any
+remedy for such violation.
+
+Except for uses explicitly permitted in this License, Ava Labs retains all
+rights in the Licensed Software, including without limitation the ability to
+modify it.
+
+Except as required or explicitly permitted by this License, you will not use
+any Ava Labs names, logos, or trademarks without Ava Labs’ prior written
+consent.
+
+You may use this License for software other than the “Licensed Software”
+specified above, as long as the only change to this License is the definition
+of the term “Licensed Software.”
+
+The Licensed Software may reference third party components. You acknowledge
+and agree that these third party components may be governed by a separate
+license or terms and that you will comply with them.
+
+**TO THE MAXIMUM EXTENT PERMITTED BY LAW, THE LICENSED SOFTWARE IS PROVIDED
+ON AN “AS IS” BASIS, AND AVA LABS EXPRESSLY DISCLAIMS AND EXCLUDES ALL
+REPRESENTATIONS, WARRANTIES AND OTHER TERMS AND CONDITIONS, WHETHER EXPRESS OR
+IMPLIED, INCLUDING WITHOUT LIMITATION BY OPERATION OF LAW OR BY CUSTOM,
+STATUTE OR OTHERWISE, AND INCLUDING, BUT NOT LIMITED TO, ANY IMPLIED WARRANTY,
+TERM, OR CONDITION OF NON-INFRINGEMENT, MERCHANTABILITY, TITLE, OR FITNESS FOR
+PARTICULAR PURPOSE. YOU USE THE LICENSED SOFTWARE AT YOUR OWN RISK. AVA LABS
+EXPRESSLY DISCLAIMS ALL LIABILITY (INCLUDING FOR ALL DIRECT, CONSEQUENTIAL OR
+OTHER DAMAGES OR LOSSES) RELATED TO ANY USE OF THE LICENSED SOFTWARE.**

README.md

@@ -34,48 +34,13 @@ The E2E test flow:
 4. Sends a transaction to update the price feed value on the C-Chain, as would be done by an oracle provider. 
 5. Imports the price feed update event into the Subnet by constructing a Warp signature of the block hash that it occured in on the C-Chain, constructing a Merkle proof for the transaction receipt the event was contained in, and broadcasting this information to the Subnet by calling the `importEvent` interface function of the `PriceFeedImporter` contract.
 
-# High Level Project Plan
-This repo is a proof-of-concept of the idea described above. In order to turn it into a production ready framework it needs to be expanded and made more robust.
-
-## Objective and Use Cases
-It should be incredibly easy for a new Subnet to securely receive event emissions and state changes from contracts on other chains. Unlike the `TeleporterMessenger` contracts which provide point-to-point messaging from one chain to another to be used in building cross-chain applications, this primitive allows for arbitrary data to be imported into a Subnet from other chains without any interaction required on the other chains.
-
-This could be used to:
-- Prove an address holds an NFT/NTT issued on other chains
-    - Could be used to give special access within games to holders of rare badges/coupons on other chains
-    - Could be used to build Avalanche-based ID/credentials
-    - etc
-- Import event feeds from other chains such as price feeds.
-
-## Open Questions by Component
-### Solidity Contract Utilities
-
-#### Requirements 
-The Solidity utility contract must support:
-- Receiving Warp block hash messages.
-- Taking an RLP encoded block header and verifying that it matches a block hash authenticated using Warp.
-- Verifying a Merkle proof of an RLP encoded receipt against the receipt root of a block header.
-- Verifying a Merkle proof of a contracts state against the state root of a block header.
-- RLP decoding of block headers and receipts.
-
-#### Open Questions and Considerations
-- Can/Should block hashes authenticated via Warp messaged be stored such that they can be used to prove arbitrarily many events going forward without having to re-verify a Warp aggregate signature?
-- Is the Merkle proof verification or RLP decoding too expensive gas-wise, and can they be optimized?
-- What frameworks should we have to decide which events are valid to be imported by an application? (i.e. strict ordering, most recent only, archival, etc)
-- Should we add a mechanism to define incentives for deliverers of events that meet certain criteria? Could we safely use the native minter precompile to guarantee profitability of deliverers (i.e. refund the transaction fee + some additional amount)?
-
-### Publisher Service and/or AWM Relayer Extension
-#### Requirements
-There should be an application that can be configured and run out-of-the-box to publish specified events to pre-configured event receiver contracts. There should be an API made available for UIs to fetch an aggregate signature of a block hash itself, such that users can easily send their own transactions to import events.
-
-#### Open Questions and Considerations
-- How can we ensure that a "get Warp signature" public API is not a DOS vector? Pre-emptively generate and cache signatures for blocks to serve on request?
-- Should a service to publish pre-configured events be embedded within the AWM relayer itself? Or should it be its own service/sidecar that is pointed to an API to be able to fetch Warp signatures when needed?
-- What are the necessary configuration settings?
-    - How to know which events to publish?
-    - How to know where to publish them to?
-    - How to check for profitability of publishing an event?
-
-
-
-
+## Open Questions and Considerations
+- Can/Should block hash authenticated via Warp messages be stored such that they can be used to prove arbitrarily many events going forward without having to re-verify a Warp aggregate signature?
+- Is the Merkle proof verification or RLP decoding prohibitively expensive gas-wise? Can they be optimized if so? How does gas usage scale with the number of receipts in the block including the event to be imported?
+- Is the delay from the time an event is emitted on a source chain to when it is imported on another chain a non-starter for certain applications? 
+    - For instance, when importing a price feed stream, it is known what the next value to be imported will be before it is actually imported.
+    - If yes, what is the acceptable delay, or how can the risk be mitigated? Note that some delay already exists in the single chain case from when the transaction hits the mempool of the source chain to when it gets included in a block.
+- How can relayers be incentivized to deliver new events that meet certain criteria?
+- What is the preferred mechanism for delivering events to be imported on other chains?
+    - Could take the form of a relayer application that listens for certain events and sends them along with the required proof to be imported to pre-configured chains and contracts.
+    - Could take the form of a public "get Warp block signature" API, that allows UIs to construct transactions importing events from other chains. In this model, users would import their own events from their wallet. The API service could potentially pre-emptively construct the aggregate signature for each block on the set of supported chains such that it can serve them on request without needing to query validators for their individual BLS signatures.