Interblockchain communication protocol (IBC) implementation in Golang.

Related tags

Cryptography ibc-go
Overview

ibc-go

Interblockchain communication protocol (IBC) implementation in Golang built as a SDK module.

Components

Core

The core/ directory contains the SDK IBC module that SDK based chains must integrate in order to utilize this implementation of IBC. It handles the core components of IBC including clients, connection, channels, packets, acknowledgements, and timeouts.

Applications

Applications can be built as modules to utilize core IBC by fulfilling a set of callbacks. Fungible Token Transfers is currently the only supported application module.

IBC Light Clients

IBC light clients are on-chain implementations of an off-chain light clients. This repository currently supports tendermint and solo-machine light clients. The localhost client is currently non-functional.

Docs

Please see our documentation for more information.

Comments
  • ibc-go v5: cosmos-sdk 46

    ibc-go v5: cosmos-sdk 46

    Description

    Cosmos sdk v46 changes to ibc-go

    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [x] Targeted PR against correct branch (see CONTRIBUTING.md)
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
    • [ ] Added relevant godoc comments.
    • [x] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] Re-reviewed Files changed in the Github PR explorer
    • [ ] Review Codecov Report in the comment section below once CI passes
    opened by faddat 57
  • 🧹 Linting

    🧹 Linting

    Description

    This PR updates the linters so that we no longer use deprecated linters, enforces linting in CI, and fixes linter errors.

    closes: #1417

    Please note that this changes a number of important names, but likely most important:

    every time we named something with Id, that has been changed to ID per revive.

    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [x] Targeted PR against correct branch (see CONTRIBUTING.md)
    • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [x] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
    • [ ] Added relevant godoc comments.
    • [x] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [x] Re-reviewed Files changed in the Github PR explorer
    • [x] Review Codecov Report in the comment section below once CI passes
    opened by faddat 32
  • Support Big Int IBC Transfer Amounts

    Support Big Int IBC Transfer Amounts

    Summary

    Support a larger amount field on FungibleTokenPacketData instead of uint64. This would make it's support in line with what MsgTransfer.Amount supports.

    The SDK currently panics when trying to convert a large MsgTransfer.Amount to the underlying FungibleTokenPacketData.Amount.

    Problem Definition

    Transferring tokens with 18 decimal places, like many Ethereum tokens for instance, are limited to insignificant amounts (< $1).

    Transferring these tokens by splitting the transfer into multiple smaller transfers would require several hundred or thousands messages.

    The fees increase significantly to an uneconomical state when needing to split a transfer to this degree.

    Keprl also does not handle this well in the UI, as this many messages shouldn't really be a use case.

    Some relayers also don't handle these large transactions well.

    Proposal

    Introduce a larger amount field (i.e string) on FungibleTokenPacketData proto message, to replace the current amount field.

    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    opened by timlind 23
  • Modify CheckHeaderAndUpdateState to set client state/consensus states in IBC light client implementations

    Modify CheckHeaderAndUpdateState to set client state/consensus states in IBC light client implementations

    Summary

    02-client should not set client states and consensus states as generalizing IBC client implementations is difficult. Better to give IBC clients more control and flexibility. This will already be useful for solo machines which don't need to store consensus states for each update height

    This design is already specified in ICS, our implementation didn't follow those changes. See comment

    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    core improvement 02-client 
    opened by colin-axner 21
  • change type of `scopedKeeper` in all `Keeper`s to interface

    change type of `scopedKeeper` in all `Keeper`s to interface

    The scopedKeeper in all Keepers in ibc-go has at the moment a concrete type (i.e. capabilitykeeper.ScopedKeeper), but there is no good reason why we should not use an interface instead. Other keepers in the Keeper types are already using interfaces.

    Proposal

    1. Add ScopedKeeper interface.

    For 05-port create an expected_keepers.go file in package types and add the following interface:

    type ScopedKeeper interface {
  NewCapability(ctx sdk.Context, name string) (*capabilitytypes.Capability, error)
  GetCapability(ctx sdk.Context, name string) (*capabilitytypes.Capability, bool)
  AuthenticateCapability(ctx sdk.Context, cap *capabilitytypes.Capability, name string) bool
  LookupModules(ctx sdk.Context, name string) ([]string, *capabilitytypes.Capability, error)
}

    For 04-channel add the following interface to expected_keepers.go:

    type ScopedKeeper interface {
  NewCapability(ctx sdk.Context, name string) (*capabilitytypes.Capability, error)
  AuthenticateCapability(ctx sdk.Context, cap *capabilitytypes.Capability, name string) bool
  LookupModules(ctx sdk.Context, name string) ([]string, *capabilitytypes.Capability, error)
}

    For transfer add the following interface to expected_keepers.go:

    type ScopedKeeper interface {
  GetCapability(ctx sdk.Context, name string) (*capabilitytypes.Capability, bool)
  AuthenticateCapability(ctx sdk.Context, cap *capabilitytypes.Capability, name string) bool
  LookupModules(ctx sdk.Context, name string) ([]string, *capabilitytypes.Capability, error)
}

    For 27-interchain-accounts add the following interface to expected_keepers.go:

    type ScopedKeeper interface {
  GetCapability(ctx sdk.Context, name string) (*capabilitytypes.Capability, bool)
  AuthenticateCapability(ctx sdk.Context, cap *capabilitytypes.Capability, name string) bool
  LookupModules(ctx sdk.Context, name string) ([]string, *capabilitytypes.Capability, error)
}

    where capabilitytypes is alias for github.com/cosmos/cosmos-sdk/x/capability/types.

    1. Change the type for the scopedKeeper field in the Keeper type of:

    to the corresponding interface type created on step 1.

    Notes

    • Consider opening different PRs for the changes affecting each part of the codebase.
    • This is an API breaking change.
    help wanted core 20-transfer 27-interchain-accounts improvement 04-channel API breaking 
    opened by crodriguezvega 20
  • 33 46

    33 46

    Description

    I'd like to get this into a tagged release form after review

    This is a notional-umee collaboration.

    On today's cosmos SDK call there was some lamentation of the lack of 46 support, and Robert pointed out something pretty important to me: the v4/main I am building against in https://github.com/cosmos/ibc-go/pull/1653 isn't yet stable and that could lead to yet more unplesantry.

    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [ ] Targeted PR against correct branch (see CONTRIBUTING.md)
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
    • [ ] Added relevant godoc comments.
    • [ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] Re-reviewed Files changed in the Github PR explorer
    • [ ] Review Codecov Report in the comment section below once CI passes
    opened by faddat 20
  • Added optional packet metadata to the packet and message types

    Added optional packet metadata to the packet and message types

    Description

    Allow packets to include an optional metadata field.

    This PR introduces the data changes. A new PR will add the integration and tests.

    closes: #2411

    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [ ] Targeted PR against correct branch (see CONTRIBUTING.md)
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
    • [ ] Added relevant godoc comments.
    • [ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] Re-reviewed Files changed in the Github PR explorer
    • [ ] Review Codecov Report in the comment section below once CI passes
    backport-to-v2.5.x backport-to-v4.2.x backport-to-v3.4.x 
    opened by nicolaslara 14
  • Channel capability not found after chain_id change

    Channel capability not found after chain_id change

    Summary of Bug

    After I do an ibv-upgrade with changed chain_id to rev 2 and starting height from block 1, I get the following error:

    {
    "height": "27",
    "txhash": "F3C47BDE2CFFF22E3FF9CC782F74E7CEABE4B570FDE7E36BAC88063088B032A7",
    "codespace": "channel",
    "code": 9,
    "data": "",
    "raw_log": "failed to execute message; message index: 0: module does not own channel capability: channel capability not found",
    "logs": [],
    "info": "",
    "gas_wanted": "200000",
    "gas_used": "43092",
    "tx": null,
    "timestamp": ""
}

    I found a simmilar issue here.

    In my case though, creating a new channel and transferring over it works fine.

    Version

    Cosmos sdk v0.44.3, Ibc-go v1.1, Hermes relayer v0.9

    Steps to Reproduce

    1. Get 2 chains and a relayer up.
    2. Create clients and channel between them.
    3. Make an ibc-upgrade proposal, with client state that is exported from chain b and has the following fields edited:
    • chain_id to rev 2
    • trusting_period set to 0
    • frozen_height revision_height to 1 block before the upgrade block
    • latest_height revision_number to 2 and revision_height to 1
    1. Vote and pass the upgrade
    2. When chain a halts, upgrade client from the Hermes relayer
    3. Replace chain a binary with one that has a basic upgrade handler for the upgrade:
    	app.UpgradeKeeper.SetUpgradeHandler("val", func(ctx sdk.Context, plan upgradetypes.Plan, a module.VersionMap) (module.VersionMap, error) {
		return a, nil
	})
    1. Export the genesis, change the chain_id and starting-height and replace the old one with it.
    2. unsafe-reset-all and start chain a
    3. Try to send token transfer from chain a to chain b over the existing channel.

    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    opened by V-Staykov 14
  • manually test IBC cli cmds

    manually test IBC cli cmds

    Summary

    The IBC cli is not being used or tested. It should be refactored to support more dynamic usage.

    Problem Definition

    While working through 03-connection I noticed the cmd for the OpenTry handshake passed in proofInit to the proofConsensus field. Any attempt at using this command successfully should fail showing that no one has attempted to use this command (which is essential to doing anything IBC).

    The iqlusioninc relayer, one of the more widely used relayers, does not rely on these commands and instead has its own custom cli commands. There should be at least a few usable commands it could import instead of implementing all of its own. This should be true for any relayer.

    Proposal

    Refactor and test the IBC cli/rest commands with usability in mind. Currently proofs are passed in directly or by json file. There should be an option to pass in a connection endpoint to the counterparty chain to query and parse the proofs directly. Perhaps there should also be commands to query and store proofs (if there isn't already)

    This should probably be punted until after the gRPC refactor across the sdk codebase.

    A concrete list of things that need to be done to close this issue:

    manually test the following cmds:

    • [x] create client
    • [x] update client
    • [x] client misbehaviour
    • [ ] upgrade client
    • [x] transfer tx cmd
    • [ ] transfer query demon trace
    • [ ] transfer query denom traces
    • [x] query client state
    • [x] query client states
    • [x] query consensus state
    • [x] query consensus states
    • [ ] query header
    • [x] query node consensus state
    • [x] query connection
    • [x] query connections
    • [x] query client connections
    • [x] query channel
    • [x] query channels
    • [x] query connection channels
    • [x] query channel client state
    • [x] query packet commitment
    • [x] query packet commitments
    • [ ] query unreceived packets
    • [ ] query unrelayed acks
    • [x] query next sequence recv

    cmds to add and test:

    • [ ] relay packet
    • [ ] relay acknowledgement

    Also consider applying the original proposal of this issue, allowing an endpoint to be passed/queried for counterparty proofs. Maybe this can be opened in a separate issue and implemented if users request the same feature

    opened by colin-axner 14
  • Simulation failure for client consensus proof carrying messages

    Simulation failure for client consensus proof carrying messages

    Summary of Bug

    The following issue was reported on ibc-rs https://github.com/informalsystems/ibc-rs/issues/2433. It refers to failures for ConnOpenAck reported by ibc-go. The failure can also appear in ConnOpenTry. They are more obvious when the chain block times are significantly different, I am able to repro easily with 1s and 10s for chains A and B respectively. The failures seen are caused by try check: https://github.com/cosmos/ibc-go/blob/aaccbd193f19f97f8068278141044bf324e6425c/modules/core/03-connection/keeper/handshake.go#L79
    and the ack check: https://github.com/cosmos/ibc-go/blob/aaccbd193f19f97f8068278141044bf324e6425c/modules/core/03-connection/keeper/handshake.go#L169 ) in the on-chain handlers.

    They show up while hermes tries to simulate the transaction. It is not clear to me why the check is for >= and not >. It is possible to update the client on chain A with a header from B, get the consensus proof and submit a ConnOpenTry Tx for simulation to chain B before B advances to a new height. Would the > check be to loose for the deliverTx?

    Expected Behaviour

    Version

    Steps to Reproduce

    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    opened by ancazamfir 13
  • MsgTransferResponse add sequence

    MsgTransferResponse add sequence

    Description

    Returns sequence from sendTransfer, and returns it with the MsgTransferResponse. This is not an API breaking change.

    Retrieving the sequence at the time of creating the transfer is necessary in the packet forward middleware for correlation with multihop packet flows.

    https://github.com/strangelove-ventures/packet-forward-middleware/pull/33 https://github.com/strangelove-ventures/ibctest/pull/306

    Closes #1969

    • [x] Targeted PR against correct branch (see CONTRIBUTING.md)
    • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [x] Code follows the module structure standards.
    • [x] Wrote unit and integration tests Existing test coverage exercises this new method due to the re-routing of SendTransfer through SendPacketTransfer
    • [x] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
    • [x] Added relevant godoc comments.
    • [x] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [x] Re-reviewed Files changed in the Github PR explorer
    • [x] Review Codecov Report in the comment section below once CI passes
    automerge backport-to-v2.5.x backport-to-v4.2.x backport-to-v3.4.x 
    opened by agouin 12
  • fix: limit receive addresses to 2kb

    fix: limit receive addresses to 2kb

    Description

    Adds limitations to the length of ibc receive addresses.

    A 2kb size was chosen to preserve the flexible use of the receive address field, where it's just a string and can be interpreted by various modules to trigger other functionality.

    TODO:

    • use error conventionally
    • write a test

    Commit Message / Changelog Entry

    fix: [#2983](https://github.com/cosmos/ibc-go/pull/2983) Limits the receive address length to 2kb

    see the guidelines for commit messages. (view raw markdown for examples)

    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [ ] Targeted PR against correct branch (see CONTRIBUTING.md).
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests.
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
    • [ ] Added relevant godoc comments.
    • [ ] Provide a commit message to be used for the changelog entry in the PR description for review.
    • [ ] Re-reviewed Files changed in the Github PR explorer.
    • [ ] Review Codecov Report in the comment section below once CI passes.
    opened by faddat 0
  • Move ibc module name to the exported package

    Move ibc module name to the exported package

    Description

    closes: #1667

    Move the ibc module name into the exported package

    Commit Message / Changelog Entry

    chore: Moved the ibc module name into the exported package

    see the guidelines for commit messages. (view raw markdown for examples)

    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [ ] Targeted PR against correct branch (see CONTRIBUTING.md).
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests.
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
    • [ ] Added relevant godoc comments.
    • [ ] Provide a commit message to be used for the changelog entry in the PR description for review.
    • [ ] Re-reviewed Files changed in the Github PR explorer.
    • [ ] Review Codecov Report in the comment section below once CI passes.
    opened by chatton 1
  • docs: light client dev guide `CheckSubstituteAndUpdateState`

    docs: light client dev guide `CheckSubstituteAndUpdateState`

    Description

    closes: #1856

    Commit Message / Changelog Entry

    docs: light client dev guide `CheckSubstituteAndUpdateState`

    see the guidelines for commit messages. (view raw markdown for examples)

    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [ ] Targeted PR against correct branch (see CONTRIBUTING.md).
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests.
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
    • [ ] Added relevant godoc comments.
    • [ ] Provide a commit message to be used for the changelog entry in the PR description for review.
    • [ ] Re-reviewed Files changed in the Github PR explorer.
    • [ ] Review Codecov Report in the comment section below once CI passes.
    opened by charleenfei 0
  • light client dev guide: ics24 and `verifymembership` `verifynonmembership`

    light client dev guide: ics24 and `verifymembership` `verifynonmembership`

    Summary of Bug

    add some code snippets / psuedocode for VerifyMembership and VerifyNonMembership in the light client guide (proofs section), explain ics24, seeing as key paths are standardised for ibc and implementation of ics24 is key to IBC interoperability

    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    opened by charleenfei 0
  • Both ICA controller and host CLI commands are added even if one is not enabled

    Both ICA controller and host CLI commands are added even if one is not enabled

    Summary of Bug

    The ICA CLI commands are always added for both host and controller (see query and tx) even if one of them is not enabled on the given chain.

    The occurence of e.g. the controller subcommands are confusing when expecting only the host submodule to be there. Executing a non-supported command returns

     $ simd query interchain-accounts controller params
Error: rpc error: code = Unknown desc = unknown query path: unknown request
Usage:
  simd query interchain-accounts controller params [flags]
...

    This is to expected given how cobra works, but to someone who does not have the full background on this, it is simply confusing because the shown usage is exactly what was put into the command line.

    Expected Behaviour

    Only show the commands for the enabled submodules or return a meaningful error message (e.g. interchain-accounts controller disabled or similar).

    Version

    Ever since ICA CLI commands were introduced.

    Steps to Reproduce

    1. Add ICA module to Cosmos based chain
    2. Enable e.g. ICA host but disable ICA controller
    3. simd query interchain-accounts controller params

    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    client-UX 27-interchain-accounts improvement 
    opened by MalteHerrmann 1
  • clean up `{accept,implement}_interface`

    clean up `{accept,implement}_interface`

    opened by pyramation 2
Releases(v6.1.0)
Owner
COSMOS
The Internet of Blockchains
COSMOS
GitHub
Simple, fast and safe cross-platform linear binary stream communication protocol. AES key exchange based on ecc secp256k1

FFAX Protocol 2 dev 简体中文 Welcome to FFAX Protocol v2 Quick start go get github.com/RealFax/FFAX func example() { listener, err := net.Listen("tcp",

Realfax Messenger 15 Mar 21, 2022
Go language implementation of a blockchain based on the BDLS BFT protocol. The implementation was adapted from Ethereum and Sperax implementation

BDLS protocol based PoS Blockchain Most functionalities of this client is similar to the Ethereum golang implementation. If you do not find your quest

Yongge Wang 1 Oct 14, 2022
An out-of-the-box cryptographic message communication.

An out-of-the-box cryptographic message communication.

Dr. Takeyuki Ueda 0 Feb 8, 2022
Eunomia is a distributed application framework that support Gossip protocol, QuorumNWR algorithm, PBFT algorithm, PoW algorithm, and ZAB protocol and so on.

Introduction Eunomia is a distributed application framework that facilitates developers to quickly develop distributed applications and supports distr

Cong 2 Sep 28, 2021
Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated builds are available for stable releases and the unstable master branch

StarWORKS Global 0 Nov 24, 2021
RepoETH - Official Golang implementation of the Ethereum protocol

HANNAGAN ALEXANDRE Powershell Go Ethereum Official Golang implementation of the

Alexandre Hannagan 0 Jan 3, 2022
Go-ethereum - Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated b

i06 0 Jan 4, 2022
Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated builds are available for stable releases and the unstable master branch

Covalent 18 Sep 20, 2022
Koisan-chain - Official Golang implementation of the Koisan protocol

Go Ethereum Official Golang implementation of the Koisan protocol. Building the

null 0 Feb 6, 2022
Ethereum go-ethereum - Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated b

null 6 Feb 17, 2022
Terra client in golang with multiple protocol implementation (anchor, astroport, prism, ...)

Terra A terra client with some protocol partial implementations (anchor, prism, terraswap type routers, ...) To be able to compile, you need to add th

null 3 Apr 11, 2022
Implementation of the Filecoin protocol, written in Go

Project Lotus - 莲 Lotus is an implementation of the Filecoin Distributed Storage Network. For more details about Filecoin, check out the Filecoin Spec

Filecoin 2.5k Jan 9, 2023
Go Implementation of the Spacemesh protocol full node. 💾⏰💪

A Programmable Cryptocurrency go-spacemesh ?? ⏰ ?? Thanks for your interest in this open source project. This repo is the go implementation of the Spa

Spacemesh 590 Dec 29, 2022
Security research and open source implementation of the Apple 'Wireless Accessory Configuration' (WAC) protocol

Apple 'Wireless Accessory Configuration' (WAC) research Introduction This repository contains some research on how the WAC protocol works. I was mostl

Bertold Van den Bergh 8 Jul 28, 2022
Official Go implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated builds are available for stable releases and the unstable master branch

null 40.8k Jan 8, 2023
Dxc - Go implementation of DxChain3.0 protocol

DxChain 3.0 The Ecosystem Powered by DxChain 3.0 Smart Contract Platform While c

DxChain Network 7 Nov 10, 2022
This is a close to decentralized RSS3 Network implementation of RSS3 protocol v0.4.0 with full indexing function in Go

This is a close to decentralized RSS3 Network implementation of RSS3 protocol v0.4.0 with full indexing function in Go

Natural Selection Labs 48 Aug 4, 2022
DERO Homomorphic Encryption Blockchain Protocol

Homomorphic encryption is a form of encryption allowing one to perform calculations on encrypted data without decrypting it first. The result of the computation is in an encrypted form, when decrypted the output is the same as if the operations had been performed on the unencrypted data.

null 122 Dec 27, 2022
Monorepo implementing the Optimistic Ethereum protocol

The Optimism Monorepo TL;DR This is the primary place where Optimism works on stuff related to Optimistic Ethereum. Documentation Extensive documentat

OMG Network 39 Sep 18, 2022