Celestia -> EVM bridge

Overview

Peggo

Project Status: WIP – Initial development is in progress, but there has not yet been a stable, usable release suitable for the public. GoDoc Go Report Card Version License: Apache-2.0 Lines Of Code GitHub Super-Linter

Peggo is a Go implementation of the Peggy (Gravity Bridge) Orchestrator originally implemented by Injective Labs. Peggo itself is a fork of the original Gravity Bridge Orchestrator implemented by Althea.

Table of Contents

Dependencies

Installation

To install the peggo binary:

$ make install

How to run

Setup

First we must register the validator's Ethereum key. This key will be used to sign claims going from Ethereum to Umee and to sign any transactions sent to Ethereum (batches or validator set updates).

$ peggo tx register-eth-key \
  --cosmos-chain-id="..." \
  --cosmos-grpc="tcp://..." \
  --tendermint-rpc="http://..." \
  --cosmos-keyring=... \
  --cosmos-keyring-dir=... \
  --cosmos-from=... \
  --eth-pk=$ETH_PK

Run the orchestrator

$ peggo orchestrator \
  --eth-pk=$ETH_PK \
  --eth-rpc=$ETH_RPC \
  --relay-batches=true \
  --relay-valsets=true \
  --eth-chain-id=... \
  --cosmos-chain-id=... \
  --cosmos-grpc="tcp://..." \
  --tendermint-rpc="http://..." \
  --cosmos-keyring=... \
  --cosmos-keyring-dir=... \
  --cosmos-from=...

Send a transfer from Umee to Ethereum

This is done using the command umeed tx peggy send-to-eth, use the --help flag for more information.

If the coin doesn't have a corresponding ERC20 equivalent on the Ethereum network, the transaction will fail. This is only required for Cosmos originated coins and anyone can call the deployERC20 function on the Peggy contract to fix this (Peggo has a helper command for this, see peggo bridge deploy-erc20 --help for more details).

This process takes longer than transfers the other way around because they get relayed in batches rather than individually. It primarily depends on the amount of transfers of the same token and the fees the senders are paying.

Important notice: if an "unlisted" (with no monetary value) ERC20 token gets sent into Umee it won't be possible to transfer it back to Ethereum, unless a validator is configured to batch and relay transactions of this token.

Send a transfer from Ethereum to Umee

Any ERC20 token can be sent to Umee and it's done using the command peggo bridge send-to-cosmos, use the --help flag for more information. It can also be done by calling the sendToCosmos method on the Peggy contract.

The ERC20 tokens will be locked in the Peggy contract and new coins will be minted on Umee with the denomination peggy{token_address}. This process takes around 3 minutes or 12 Ethereum blocks.

How it works

Peggo allows transfers of assets back and forth between Ethereum and Umee. It supports both assets originating on Umee and assets originating on Ethereum (any ERC20 token).

It works by scanning the events of the contract deployed on Ethereum (Peggy) and relaying them as messages to the Umee chain; and relaying transaction batches and validator sets from Umee to Ethereum.

Events and messages observed/relayed

Ethereum

Deposits (SendToCosmosEvent): emitted when sending tokens from Ethereum to Umee using the sendToCosmos function on Peggy.

Withdraw (TransactionBatchExecutedEvent): emitted when a batch of transactions is sent from Umee to Ethereum using the submitBatch function on the Peggy contract by a validator. This serves as a confirmation to Umee that the batch was sent successfully.

Valset update (ValsetUpdatedEvent): emitted on init of the Peggy contract and on every execution of the updateValset function.

Deployed ERC 20 (ERC20DeployedEvent): emitted when executing the function deployERC20. This event signals Umee that there's a new ERC20 deployed from Peggy, so Umee can map the token contract address to the corresponding native coin. This enables transfers from Umee to Ethereum.

Umee

Validator sets: Umee informs the Peggy contract who are the current validators and their power. This results in an execution of the updateValset function.

Request batch: Peggo will check for new transactions in the Outgoing TX Pool and if the transactions' fees are greater than the set minimum batch fee, it will send a message to Umee requesting a new batch.

Batches: Peggo queries Umee for any batches ready to be relayed and relays them over to Ethereum using the submitBatch function on the Peggy contract.

Comments
  • Create a new tag for the latest master

    Create a new tag for the latest master

    Currently, when referring to the QGB repo from a Go project, it gets the v1.0.3 which is too old. We should create a new tag v1.1.0 which refers to the latest master.

    release 
    opened by SweeXordious 13
  • Investigate what to commit to

    Investigate what to commit to

    Summary

    #4 proposed including a tuple root. An alternative would simple be including the data root. Investigate and document final decision.

    Problem Definition

    Proposal


    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged
    • [ ] Contributor assigned/self-assigned
    question 
    opened by adlerjohn 6
  • fix: Change nonce to height.

    fix: Change nonce to height.

    Fixes #104

    Technically this might not even be necessary from a functional point of view; it's simply adding a constructor field for the initial height, which will be overwritten on the first update anyways. The nonce check was already <= instead of == +1.

    Documentation was updated though to make it clearer.

    contracts 
    opened by adlerjohn 5
  • [tracking] EVM light client bridge vs Gravity Bridge

    [tracking] EVM light client bridge vs Gravity Bridge

    Problem Statement

    Various rollups on EVM L1s may have a need for using Celestia as a DA layer, while keeping fraud/validity proof verification in the EVM. To that end, two concrete possibilities exist: the Gravity bridge and a native EVM light client. This issue summarizes how each will work, any changes necessary for our usecase, and pros and cons.

    Gravity Bridge

    The Gravity bridge is a project initiated in the Cosmos ecosystem: https://github.com/cosmos/gravity-bridge. Various forks (maybe as many as a dozen at this point) exist of this protocol, with minor changes. Non-exhaustively

    1. https://github.com/PeggyJV/gravity-bridge (Rust off-chain code)
    2. https://github.com/InjectiveLabs/peggo (Go off-chain code)

    Method of Operation

    The Gravity bridge has two components: an on-chain component written in Solidity and an off-chain component (the orchestrator) written in Rust (Peggy) or Go (Injective). A high-level explanation of the Solidity contracts can be found here.

    The orchestrator runs alongside a Tendermint node (potentially as an SDK module) that causes validators (i.e. block producers) to, in addition to regular Tendermint votes, also sign EVM-compatible messages that mirror:

    1. validator set changes, and
    2. arbitrary events in blocks.

    Specifically, messages are signed in accordance with ERC-191. These signatures are batched and sent to an on-chain contract. The contract keeps track of the validator set as it changes, and verifies that the arbitrary events are signed off by a supermajority of voting power.

    Updates to the validator set must occur every time

    1. The validator set changes too much (currently, 5% is recommended, though this parameter may be tweaked up to 33% I think), or
    2. No other updates have occurred within the unbonding window. For safety, probably 1/2 the unbonding window should be used here.

    To update the contract's view of the validator set, updateValset is called. The orchestrator will construct an EVM-compatible transaction with batched signatures here. The contract will simply verify that:

    1. The provided previous validator set matches the known hash of the validator set, and
    2. A supermajority of the previous validator set has voted correctly for the new validator set.

    Then update its saved validator set hash.

    I estimate this operation is ~500k gas each time. As an example, Ethereum is an EVM-compatible chain and at its current gas prices this would cost ~$400. It would be prohibitive to update the validator set every block, hence the above threshold of 5%. With only occasional updates, this cost should end up not being too significant.

    Batches of arbitrary messages are submitted to the EVM chain with submitBatch. This requires verification of the current validator set and a supermajority of signatures. Note that arbitrary messages does not necessarily imply single blocks; properly implemented, a single batch of arbitrary messages can be made across as many blocks as can fit in the gas limit.

    Required Changes

    1. Numerous gas optimizations can and should be made. Just as an example of how immature the implementation is: when updating the validator set, the new validator set is provided. But this is actually not needed under an honest majority assumption; a commitment to the new validator set is sufficient.
    2. The submitBatch function only works for transfers of fungible tokens across the bridge. This will have to be modified for our purposes, namely a list of (block height, namespace ID, message commitment) tuples.
    3. The orchestrator exists mostly as a separate module for now. It will have to be fully integrated into either the SDK or the node software directly.
    4. An audit of the contracts will be required.
    5. NMT proof verification and share parsing (but not Celestia tx parsing) is required, since the commitment is identical to the one in the PayForMessage tx. As such, a protobuf codec is not needed.

    Pros

    1. A majority of the of the code already exists. This will probably be the fastest option.
    2. Potential for Cosmos branding and association.

    Cons

    1. Realistically, there is 0% chance of being able to upstream changes, barring us owning the canonical implementation of Gravity bridge. This is because there is no specification or reference implemention of the Gravity bridge protocol, so a dozen projects each have their own completely independent fork, with more popping up. This will have to be developed in isolation of the broader Cosmos ecosystem solely for our purposes.
    2. Cost of verifying signatures for each message batch is non-trivial. Verifying 50 signatures would be ~200k gas, while simply posting them would be ~50k.
    3. Requires validators to run a module that introduces a logic dependence on the EVM, and EIP-191. In addition, this will requires computational overhead in the form of each validator needing to run a full node for the EVM chain (or trust a centralized service provider to provide them confirmation of transaction inclusion and effect).
    4. One of the key requirements for PoS is accountability: being able to identify which validators of a dishonest majority were in fact dishonest, and burning their stake with social coordination. Validators that submit a bad batch or validator set update to the EVM chain must be penalized, otherwise the bridge isn't making and honest-but-accountable-majority assumption (good), but an honest-and-unaccountable-majority assumption (bad). To that end, non-validator nodes must also be able to understand the EVM and EIP-191 in order to be able to understand that the validator submitted something they should not have, and penalize them.
    5. A separate instance of the Gravity bridge module is required to handle each chain that is bridged to. This is not yet implemented properly, but even if it were, it would be onerous in a future where potentially many chains would leverage Celestia as a DA service.

    EVM Light Client Bridge

    The EVM light client bridge (this repo) is a Celestia light client written in Solidity. It accepts new blocks headers as they are in Celestia, and follows the chain of block headers under an honest majority assumption.

    Method of Operation

    The EVM light client bridge has two components: an on-chain component written in Solidity and an off-chain component (which we'll call the orchestrator), yet to be written.

    The on-chain contract will accept new Celestia block headers in protobuf, along with addition metadata, such as the validator set (diff). It can then update its view of the validator set similar to the Gravity bridge. Again, the actual updating of the validator set is only required when a threshold of the voting power changes.

    To parse the protobuf-encoded header, the following libraries implement deterministic protobuf:

    1. https://github.com/celestiaorg/protobuf3-solidity
    2. https://github.com/celestiaorg/protobuf3-solidity-lib

    The final piece of the puzzle is that verification of the header and signatures must be done optimistically, by making the header chain an optimistic rollup. This is necessary since parsing protobuf every time would be too expensive. This would significantly reduce gas costs vs the Gravity bridge: verifying 50 signatures would be ~200k gas, while simply posting them would be ~50k. This similarly applies to processing messages. In other words, gas costs can be reduced by somewhere around a factor of 4 with an optimistic EVM light client bridge vs the Gravity bridge.

    Required Changes

    Significant changes are required.

    1. Actually use protobuf to encoding/decode headers, etc. Library is implemented but is unused.
    2. NMT proof verification, transaction and share parsing, etc.
    3. Optimistic verification and rollbacks. This is one of the easier things to implement on this list, since the author is moderately familiar with how optimistic rollups work.
    4. Off-chain orchestrator will have to be implemented, but significant portions of the Gravity bridge can be re-used.
    5. Gas optimizations for the protobuf library.
    6. An audit of the contracts will be required.

    Pros

    1. Since the contract accepts Celestia block headers directly, there is no need for validators to run any separate module. In addition, validators do not even need to run anything that connects to another chain in any ways. A single relayer can be tasked with posting all updates to the relevant EVM chain(s).
    2. There is no logical dependence on the EVM or EIP-191. The bridge operates under an honest-but-accountable-majority assumption.
    3. With optimistic verification, gas costs can be reduced significantly vs the Gravity bridge.
    4. Potential to maintain potentially widely-used optimistic Tendermint light client bridge and reference implementation of deterministic protobuf codec Solidity library.

    Cons

    1. Large parts of the Solidity code are missing, including actually using the protobuf codec, NMT proof verification, transaction and share parsing, etc.
    2. An orchestrator will have to be implemented to actually send transactions to Ethereum. The Gravity orchestrator can be re-used mostly.
    3. With optimistic verification, a delay is required to finalize the submitted block headers. This may be unacceptable for zk rollup projects, but is fine for optimistic rollups.

    Discussion

    Don't forget to like, comment, and subscribe 👇

    opened by adlerjohn 5
  • feat: Add oracle interface

    feat: Add oracle interface

    Adds a publicly callable interface for downstream contracts to query the QGB contract for attestations.

    Depends on #32

    Tests will be done in a future PR.

    enhancement 
    opened by adlerjohn 4
  • Contract not verifying valsets against the right checkpoint

    Contract not verifying valsets against the right checkpoint

    Currently, the QGB contract, when submitting valsets, creates the following checkpoint: https://github.com/celestiaorg/quantum-gravity-bridge/blob/210a1fbb9a9fc3165a038d8cedfba177c67a5726/src/QuantumGravityBridge.sol#L275

    The issue, is that the checkpoint is calculated using the currentNonce which is the latest eventNonce, and will never match the submitted one.

    Example: We relay the following attestations:

    • Nonce 1 : Valset 1
    • Nonce 2 : DC
    • Nonce 3 : DC
    • Nonce 4 : Valset 2

    When submitting the Valset 1 with Nonce = 1, the checkpoint will be calculated using Nonce = 1. However, when submitting Valset 2 with Nonce = 4, the checkpoint, which the contract will check against, will be created using Nonce = 3, resulting in a wrong checkpoint.

    The solution would be to keep a LastValsetNonce variable stored in the contract, so that when submitting the new checkpoint, it can be used to generate the validator set hash correctly.

    @adlerjohn @evan-forbes

    bug 
    opened by SweeXordious 3
  • Clean up contracts

    Clean up contracts

    Main contract: https://github.com/celestiaorg/quantum-gravity-bridge/blob/adlerjohn/contract_mods/ethereum/solidity/contracts/QuantumGravityBridge.sol

    Original main contract: https://github.com/celestiaorg/quantum-gravity-bridge/blob/b5ba246f23f89c43adf764e2e3f804b4a9f3beb0/solidity/contracts/Peggy.sol

    opened by adlerjohn 3
  • Delete mergify config

    Delete mergify config

    Description

    This is an attempt to fix: https://github.com/celestiaorg/quantum-gravity-bridge/pull/124/checks?check_run_id=7962233579

    ~~strict and commit_message aren't supported keys for actions.merge (ref https://docs.mergify.com/actions/merge/). It looks possible to use commit_message_template to achieve something similar to the previous commit_message config if desired.~~

    bug 
    opened by rootulp 2
  • update the generated wrapper

    update the generated wrapper

    When I regenerate the wrapper, it gives me different BINs. @adlerjohn please take a look when you have time. The compiler that I used is:

    Version: 0.8.4+commit.c7e474f2.Linux.g++
    
    help wanted 
    opened by SweeXordious 2
  • Orchestrator read pay for message txs from node

    Orchestrator read pay for message txs from node

    #9 will mock what is sent to the contract. PayForMessage txs must be extracted from each Celestia block and replace the mock logic so that real data can be sent to the contract.

    enhancement 
    opened by adlerjohn 2
  • chore: bump github.com/cosmos/cosmos-sdk from 0.44.3 to 0.44.4

    chore: bump github.com/cosmos/cosmos-sdk from 0.44.3 to 0.44.4

    Bumps github.com/cosmos/cosmos-sdk from 0.44.3 to 0.44.4.

    Release notes

    Sourced from github.com/cosmos/cosmos-sdk's releases.

    Cosmos SDK v0.44.4 Release Notes

    This release introduces bug fixes and improvements in the Cosmos SDK v0.44 series.

    SDK v0.44.0-v0.44.3 x/auth migration have a vesting account bug, which vanishes delegated_vesting field from BaseVestingAccount. Recovery, unfortunately, is complicated and either involves manually overwriting it or querying an old state. We had to change the order of module migration by pushing x/auth to the end. Auth module state depends on x/stake and should be run last. We have updated the documentation to provide more details how to change module migration order. This is technically a breaking change, but only impacts updates between the major version change, hence migrating from the previous patch release (0.44.x) doesn't cause new migration and doesn't break the state.

    Other bug fixes:

    • grpc-gateway query account balance by IBC denom had an incorrect endpoint (correct one is "/cosmos/bank/v1beta1/balances/{address}/by_denom")
    • use sdk.GetConfig().GetFullBIP44Path() instead sdk.FullFundraiserPath to generate key - this correctly resets hdpath when running app testnet.

    This release enables Auto Download feature for Cosmovisor >= v1.0.0. Now, you will be able to use Auto Download with the latest Cosmovisor when you will plan the next upgrade to the next major release (v0.45.0),

    Finally, we updated the IAVL to v0.17.2 and take a benefit of the new IAVL iterator, which improves the iteration performance.

    See the Cosmos SDK v0.44.4 Changelog for the exhaustive list of all changes.

    Full Diff: https://github.com/cosmos/cosmos-sdk/compare/v0.44.3...v0.44.4

    Changelog

    Sourced from github.com/cosmos/cosmos-sdk's changelog.

    v0.44.4 - 2021-11-25

    Improvements

    • (x/upgrade) #10532 Add keeper.DumpUpgradeInfoWithInfoToDisk to include Plan.Info in the upgrade-info file.
    • (store) #10544 Use the new IAVL iterator structure which significantly improves iterator performance.

    Bug Fixes

    • #10414 Use sdk.GetConfig().GetFullBIP44Path() instead sdk.FullFundraiserPath to generate key
    • (bank) #10394 Fix: query account balance by ibc denom.
    • \10608 Change the order of module migration by pushing x/auth to the end. Auth module depends on other modules and should be run last. We have updated the documentation to provide more details how to change module migration order. This is technically a breaking change, but only impacts updates between the upgrades with version change, hence migrating from the previous patch release doesn't cause new migration and doesn't break the state.
    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    T:Dependencies A:Automerge 
    opened by dependabot[bot] 2
  • Add CI workflow to require labels for PRs

    Add CI workflow to require labels for PRs

    As per the discussion in https://github.com/celestiaorg/quantum-gravity-bridge/pull/106#issuecomment-1087539242 , we need to add the following workflow to require PRs to have a minimum of 1 label.

    good first issue github_actions 
    opened by SweeXordious 2
  • Look into removing the `BRIDGE_ID`

    Look into removing the `BRIDGE_ID`

    Since we're a one way bridge, we might be able to remove the BRIDGE_ID that is normally used to prevent replay attacks. We should further investigate the consequences of removing it.

    contracts optimization 
    opened by evan-forbes 0
  • Write ADR for dynamic data commitment block ranges

    Write ADR for dynamic data commitment block ranges

    The QGB relies on validators signing commitments to erasure block data over a range of blocks. For the MVP, we are using an identical block range for each DataCommitment. This range of blocks will likely need to be significantly more dynamic to accommodate different rollups.

    • How can we do this in an efficient way?
    • Does it matter if ranges overlap?
    • How will this affect slashing?
    • Will the rollup batch producers need to ask the celestia validators to sign commitments over custom ranges? If so, what should that look like?
    • Do any changes need to be made to the contracts?
    documentation 
    opened by evan-forbes 0
Releases(v1.2.0)
  • v1.2.0(Jun 22, 2022)

    What's Changed

    • Use old validator set nonce instead of latest nonce. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/121

    Full Changelog: https://github.com/celestiaorg/quantum-gravity-bridge/compare/v1.1.0...v1.2.0

    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Jun 6, 2022)

    What's Changed

    • Merge in umee peggo by @liamsi in https://github.com/celestiaorg/quantum-gravity-bridge/pull/5
    • Clean up contracts by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/3
    • chore: fix build and wrapper generation & regenerate by @liamsi in https://github.com/celestiaorg/quantum-gravity-bridge/pull/8
    • chore: bump github.com/golangci/golangci-lint from 1.42.1 to 1.43.0 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/10
    • ci: main -> master by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/15
    • Make readme Celestia- and QGB-specific by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/38
    • chore: bump actions/cache from 2.1.6 to 2.1.7 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/11
    • chore: bump technote-space/get-diff-action from 5 to 6.0.1 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/29
    • chore: bump amannn/action-semantic-pull-request from 3.4.6 to 4.2.0 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/52
    • chore: bump actions/setup-go from 2.1.4 to 2.2.0 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/53
    • fix: Fix codeowners Solidity dir. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/61
    • chore: bump actions/setup-go from 2.2.0 to 3 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/62
    • chore: bump actions/checkout from 2 to 3 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/63
    • feat: Add Merkle tree libraries by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/32
    • feat: Use Foundry and add Merkle tree tests by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/51
    • chore: Remove issue templates by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/69
    • chore: Remove codeowner by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/68
    • fix: Use minimum solc v0.8.4 by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/70
    • fix: Allow skipping nil signatures. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/72
    • chore: Remove unused contracts and wrappers. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/74
    • fix: Fix paths for abigen by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/75
    • chore: Regenerate contract ABI bindings. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/76
    • chore: Clean up readme. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/78
    • chore: Remove old contract docs. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/77
    • chore: Remove old Ethereum files. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/80
    • chore: Remove prettier config files. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/81
    • chore: Remove redundant ABIEncoderV2 pragmas. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/82
    • feat(ci): run forge test by @rootulp in https://github.com/celestiaorg/quantum-gravity-bridge/pull/83
    • chore: Improve readme. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/84
    • chore: Add period at end of comment. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/85
    • fix: Add prettierrc for Solidity by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/88
    • feat: Refactor and add inner node verification logic. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/92
    • chore: bump actions/cache from 2.1.7 to 3 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/94
    • chore: remove goreleaser by @rootulp in https://github.com/celestiaorg/quantum-gravity-bridge/pull/95
    • fix: use new nonce instead of current nonce by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/97
    • chore: add tests for verifyInner by @rootulp in https://github.com/celestiaorg/quantum-gravity-bridge/pull/102
    • chore: Test the main contract by @evan-forbes in https://github.com/celestiaorg/quantum-gravity-bridge/pull/100
    • chore: labels exist; use them by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/106
    • Remove references to Ethereum specifically. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/109
    • fix: Change nonce to height. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/105
    • Remove Go code and move Solidity code to root. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/113
    • chore: bump actions/checkout from 2 to 3 by @dependabot in https://github.com/celestiaorg/quantum-gravity-bridge/pull/114
    • Improve readme for Forge. by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/116
    • Universal nonce by @adlerjohn in https://github.com/celestiaorg/quantum-gravity-bridge/pull/119

    New Contributors

    • @liamsi made their first contribution in https://github.com/celestiaorg/quantum-gravity-bridge/pull/5
    • @dependabot made their first contribution in https://github.com/celestiaorg/quantum-gravity-bridge/pull/10
    • @rootulp made their first contribution in https://github.com/celestiaorg/quantum-gravity-bridge/pull/83
    • @evan-forbes made their first contribution in https://github.com/celestiaorg/quantum-gravity-bridge/pull/100

    Full Changelog: https://github.com/celestiaorg/quantum-gravity-bridge/compare/v1.0.3...v1.1.0

    Source code(tar.gz)
    Source code(zip)
Owner
Celestia
Celestia
Dotcel - Domain name application built on top of celestia

dotcel dotcel is a blockchain built using Cosmos SDK and Tendermint and created

Evan Forbes 1 Feb 7, 2022
EVM-compatible chain secured by the Lachesis consensus algorithm

ICICB galaxy EVM-compatible chain secured by the Lachesis consensus algorithm. Building the source Building galaxy requires both a Go (version 1.14 or

Galaxy developer Team 10 Jan 8, 2022
A Matrix-iMessage puppeting bridge

A Matrix-iMessage puppeting bridge. The bridge runs on a Mac or jailbroken iPhone (soon™). A websocket proxy is required to receive appservice events from the homeserver.

Tulir Asokan 138 Sep 10, 2022
vks is a Vulkan bridge for Go.

vks vks is a Vulkan bridge for Go. The header generator folder contains the code that is used to generate the vulkan bindings. It woks similar to c-fo

Jason Watson 6 Sep 3, 2022
Bridge between mattermost, IRC, gitter, xmpp, slack, discord, telegram, rocketchat, twitch, ssh-chat, zulip, whatsapp, keybase, matrix, microsoft teams, nextcloud, mumble, vk and more with REST API

bridge between mattermost, IRC, gitter, xmpp, slack, discord, telegram, rocketchat, twitch, ssh-chat, zulip, whatsapp, keybase, matrix, microsoft teams, nextcloud, mumble, vk and more with REST API (mattermost not required!)

Wim 5.2k Sep 22, 2022
Bridge facebook messenger with any service supported by matterbridge

fbridge fbridge bridges facebook messenger with any service supported by matterbridge trough the API interface. fbridge is using fbchat to connect to

null 26 Sep 6, 2022
Facebook bridge used with matterbridge

fbridge-asyncio This repo is a fork of fbridge. If you log in to your facebook account from a browser, after you do, it's a good idea to restart fbrid

null 8 Aug 7, 2022
An inline buildpack for deploying a mattermost-irc bridge

Matterbridge-Heroku An inline buildpack for hosting Matterbridge on Heroku. Heroku is a platform for easily deploying applications. A buildpack provid

Christopher DeCairos 10 Jul 8, 2022
Grpc bridge to various mediabank related systems

Mediabank bridge This internal tool enables authenticated gRPC based endpoint for securely communicating with systems like: Telestream Vantage Workflo

BCC Code 0 Jan 7, 2022
Bridge REMOV will allow you to safely transfer NFT from RMRK to MOVR and backwards

remov Inspiration Our aim is to expand the capabilities of blockchain and make a secure way for transferring NFT between RMRK and MOVR blockchain. The

null 1 Dec 5, 2021
A REST API for the DN42 registry, written in Go, to provide a bridge between interactive applications and the registry.

dn42regsrv A REST API for the DN42 registry, written in Go, to provide a bridge between interactive applications and registry data. A public instance

Simon Marsh 0 Apr 21, 2022
The official repository of the Gravity Bridge Blockchain

Gravity bridge is Cosmos <-> Ethereum bridge designed to run on the Cosmos SDK blockchains like the Cosmos Hub focused on maximum design simplicity an

Gravity Bridge Foundation 94 Sep 23, 2022
A bridge from the Stellar network to other blockchains

Creating equitable access to the global financial system Starbridge Starbridge is software that facilitates bridge builders who are connecting the Ste

Stellar 33 Sep 19, 2022
RuuviBridge - Utility to bridge RuuviTag data between various sources and consumers

RuuviBridge RuuviBridge is designed to act as a "data bridge" between various so

Scrin 11 Sep 18, 2022
🧙 High-performance PHP-to-Golang IPC/RPC bridge

High-performance PHP-to-Golang IPC bridge Goridge is high performance PHP-to-Golang codec library which works over native PHP sockets and Golang net/r

RoadRunner 1.1k Sep 22, 2022
Apex-api-bridge - Bridge between apexlegendsapi and ApeStats

apex-api-sync This app updates a mongo instance with the players most recent dat

null 1 Feb 17, 2022
Dotcel - Domain name application built on top of celestia

dotcel dotcel is a blockchain built using Cosmos SDK and Tendermint and created

Evan Forbes 1 Feb 7, 2022
Stress testing and benchmarking tool for the NEAR EVM

evm-bully --- stress testing and benchmarking tool for the NEAR EVM

Project Aurora 28 May 30, 2022
Moeing chain is an EVM&Web3 compatible sidechain for Bitcoin Cash

Full node client of smartBCH This repository contains the code of the full node client of smartBCH, an EVM&Web3 compatible sidechain for Bitcoin Cash.

null 119 Sep 15, 2022
EVM frontrunning tool

CAKE SNIPER FRONTRUNNING BOT =================================================== BEFORE STARTING: This bot require you to run the GETH client + use

Supercycled 1.4k Sep 20, 2022