Evmos is a scalable, high-throughput Proof-of-Stake blockchain that is fully compatible and interoperable with Ethereum.

Related tags

Cryptography evmos
Overview

Evmos

Evmos is a scalable, high-throughput Proof-of-Stake blockchain that is fully compatible and interoperable with Ethereum. It's built using the Cosmos SDK which runs on top of Tendermint Core consensus engine.

Note: Requires Go 1.17+

Installation

For prerequisites and detailed build instructions please read the Installation instructions. Once the dependencies are installed, run:

make install

Or check out the latest release.

Quick Start

To learn how the Evmos works from a high-level perspective, go to the Introduction section from the documentation. You can also check the instructions to Run a Node.

Community

The following chat channels and forums are a great spot to ask questions about Evmos:

Contributing

Looking for a good place to start contributing? Check out some good first issues.

For additional instructions, standards and style guides, please refer to the Contributing document.

Careers

See our open positions on Cosmos Jobs, Notion, or feel free to reach out via email.

Comments
  • imp: enable revive rules

    imp: enable revive rules

    Description

    I have set all severity: error flags to a warning. This in the meantime will enable us to tackle each of the lint issues in individual PRs.

    Closes: #XXX


    All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.

    PR review checkboxes:

    I have...

    • [ ] added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] included the correct type prefix in the PR title
    • [ ] targeted the correct branch (see PR Targeting)
    • [ ] provided a link in the PR description to the relevant issue or specification
    • [ ] reviewed "Files changed" and left comments if necessary
    • [ ] confirmed all required CI checks have passed

    Code maintenance:

    I have...

    • [ ] written unit and integration tests
    • [ ] added relevant godoc and code comments.
    • [ ] updated relevant documentation (docs/) or specification (x/<module>/spec/)

    Reviewers Checklist

    All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.

    I have...

    • [ ] confirmed the correct type prefix in the PR title
    • [ ] confirmed all author checklist items have been addressed
    • [ ] confirmed that this PR does not change production code
    good first issue help wanted Type: CI C:Types 
    opened by fedekunze 34
  • chore: sdk v46

    chore: sdk v46

    Description

    • sdk v46
    • ibc-go v5-rc0

    This PR updates EVMOS to cosmos-sdk v0.46.1, tendermint v0.34.21, and ibc-go v5.0.0-rc1

    The changes are coupled together because ibc-go v4.0.0 is not compatible with cosmos-sdk v0.46.*

    One way to reduce the number of files changed in this PR would be to make a PR containing only the path change from github.com/evmos/evmos/v8 to github.com/evmos/evmos/v9


    All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.

    PR review checkboxes:

    I have...

    • [ ] added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] included the correct type prefix in the PR title
    • [ ] targeted the correct branch (see PR Targeting)
    • [ ] provided a link in the PR description to the relevant issue or specification
    • [ ] reviewed "Files changed" and left comments if necessary
    • [ ] confirmed all required CI checks have passed

    Code maintenance:

    I have...

    • [ ] written unit and integration tests
    • [ ] added relevant godoc and code comments.
    • [ ] updated relevant documentation (docs/) or specification (x/<module>/spec/)

    Reviewers Checklist

    All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.

    I have...

    • [ ] confirmed the correct type prefix in the PR title
    • [ ] confirmed all author checklist items have been addressed
    • [ ] confirmed that this PR does not change production code
    opened by faddat 25
  • ERR failed init node error=

    ERR failed init node error="error during handshake: error on replay: wrong Block.Header.AppHash.

    ERR failed init node error="error during handshake: error on replay: wrong Block.Header.AppHash. Expected F24F64FA2766CC94E640C503CA7462D133107DAABBEB57D7C6C619312892C14F, got 7D698782C45C70274523B407864801BF5BEEBD2C8E5FDA5E03D9CE19E05B4E1E" Error: error during handshake: error on replay: wrong Block.Header.AppHash. Expected F24F64FA2766CC94E640C503CA7462D133107DAABBEB57D7C6C619312892C14F, got 7D698782C45C70274523B407864801BF5BEEBD2C8E5FDA5E03D9CE19E05B4E1E

    version:3.0.0 mac go:1.8

    chain-id:evmos_9001-2

    Status: Stale 
    opened by craft0909 18
  • fix: IBC attestation ordering

    fix: IBC attestation ordering

    Description

    Closes: ENG-192


    All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.

    PR review checkboxes:

    I have...

    • [ ] added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] included the correct type prefix in the PR title
    • [ ] targeted the correct branch (see PR Targeting)
    • [ ] provided a link in the PR description to the relevant issue or specification
    • [ ] reviewed "Files changed" and left comments if necessary
    • [ ] confirmed all required CI checks have passed

    Code maintenance:

    I have...

    • [ ] written unit and integration tests
    • [ ] added relevant godoc and code comments.
    • [ ] updated relevant documentation (docs/) or specification (x/<module>/spec/)

    Reviewers Checklist

    All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.

    I have...

    • [ ] confirmed the correct type prefix in the PR title
    • [ ] confirmed all author checklist items have been addressed
    • [ ] confirmed that this PR does not change production code
    backport/3.0.x 
    opened by fedekunze 14
  • ENG 453 mint and allocation

    ENG 453 mint and allocation

    Description

    This PR implements two different inflation mechanisms:

    1. Linear Team Vesting

    • Initial supply of 200M is minted once at genesis and sent to unvested team account . This prevents triggering multiple taxable events that would occur if we would mint the team vesting provision daily.
    • Each epoch (each day) a constant team vesting provision is sent from the unvested team account to the team account.

    2. Exponential Inflation - The Half Life

    • Exponential inflation is calculated for staking, usage incentives and community pool, not for team vesting.
    • Inflation is minted in daily epochs. After each period of 365 epochs (one year) the amount of rewards per epoch is recalculated with the calculation below:
    f(x) describes the total inflation per year
    
    periodProvision = exponentialDecay       *  bondingRatio
    f(x)            = (a * (1 - r) ^ x + c)  *  ((2 - b) / 2)
    
    epochProvision = periodProvision / epochsPerPeriod
    
    • each param can be customised ( a, r, c, b, epochsPerPeriod)
    C:Proto C:CLI Type: Docs 
    opened by danburck 14
  • Err=

    Err="incompatible: peer is on a different network. Got evmos_9001-2, expected evmos_9001-1"

    Summary of Bug

    While syncing node from start getting error as incompatible: peer is on a different network. Got evmos_9001-2, expected evmos_9001-1

    Version

    v4.0.1

    Steps to Reproduce

    Steps followed from https://docs.evmos.org/validators/mainnet.html

    Screenshots

    image

    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged
    • [ ] Contributor assigned/self-assigned
    Status: Stale 
    opened by abbas-unmarshal 12
  • [ENG-128] Fee distribution module - x/fees

    [ENG-128] Fee distribution module - x/fees

    Description

    ~~Distributes gasUsed * baseFee to developers (contract owners) and validators.~~ Distributes gasUsed * gasPrice (legacy tx), gasUsed * effectiveGasPrice (dynamic tx) to developers (contract deployers) and validators.

    Closes: https://linear.app/tharsis/issue/ENGO-370/fee-distribution-module Closes: https://github.com/tharsis/evmos/issues/437

    Related PRs: https://github.com/tharsis/evmos/pull/461 https://github.com/tharsis/evmos/pull/464 https://github.com/tharsis/evmos/pull/469 https://github.com/tharsis/evmos/pull/471


    All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.

    PR review checkboxes:

    I have...

    • [ ] added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] included the correct type prefix in the PR title
    • [x] targeted the correct branch (see PR Targeting)
    • [x] provided a link in the PR description to the relevant issue or specification
    • [ ] reviewed "Files changed" and left comments if necessary
    • [ ] confirmed all required CI checks have passed

    Code maintenance:

    I have...

    • [x] written unit and integration tests
    • [ ] added relevant godoc and code comments.
    • [ ] updated relevant documentation (docs/) or specification (x/<module>/spec/)

    Reviewers Checklist

    All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.

    I have...

    • [ ] confirmed the correct type prefix in the PR title
    • [ ] confirmed all author checklist items have been addressed
    • [ ] confirmed that this PR does not change production code
    opened by loredanacirstea 12
  • [ENG-447] protobuf workspaces migration

    [ENG-447] protobuf workspaces migration

    Description

    • migrating protobuf code generator to protobuf workspaces
    • ticket: ENG-447
    • purpose: current proto build configuration for proto and swagger files "not reliable" (as per ticket), this PR creates a Buf Workspace in the repository and changes the iterative use of protoc -> buf build and buf generate.

    All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.

    PR review checkboxes:

    I have...

    • [ ] added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] included the correct type prefix in the PR title
    • [ ] targeted the correct branch (see PR Targeting)
    • [ ] provided a link in the PR description to the relevant issue or specification
    • [ ] reviewed "Files changed" and left comments if necessary
    • [ ] confirmed all required CI checks have passed

    Code maintenance:

    I have...

    • [ ] written unit and integration tests
    • [ ] added relevant godoc and code comments.
    • [ ] updated relevant documentation (docs/) or specification (x/<module>/spec/)

    Reviewers Checklist

    All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.

    I have...

    • [ ] confirmed the correct type prefix in the PR title
    • [ ] confirmed all author checklist items have been addressed
    • [ ] confirmed that this PR does not change production code
    C:Proto Type: Build Type: CI 
    opened by adisaran64 11
  • Panic while running mainnet node- `panic: UnmarshalJSON cannot decode empty bytes`

    Panic while running mainnet node- `panic: UnmarshalJSON cannot decode empty bytes`

    Summary of Bug

    Trying to run a node for RPC request, getting error panic: UnmarshalJSON cannot decode empty bytes

    Version

    Latest clone from github

    Steps to Reproduce

    Unzip the snapshot to /data directory evmosd start --home /data

    Screenshots

    image

    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged
    • [ ] Contributor assigned/self-assigned
    opened by abbas-unmarshal 10
  • Some metrics have unbounded cardinality

    Some metrics have unbounded cardinality

    After adding a stock Evmos full node to my infrastructure, I noticed a large impact on my Prometheus servers. A brief investigation revealed the cause to be evmosd_tx_msg_ethereum_tx_gas_limit_per_gas_used. Specifically, that metric — I believe added in this PR on evmos/ethermint? — includes a "to" label whose values are just addresses. That means that metric has unbounded cardinality, which is unfortunately a no-go for Prometheus.

    Digging around, I saw a few other instances of unbounded labelsets. Same thing applies there.

    Label values basically gotta be enums — HTTP status codes, well-defined route names, etc. If you really wanna use arbitrary data, you gotta make sure there's some reasonable upper bound to the cardinality. Any kind of Cosmos/Tendermint/etc. address doesn't work, I don't think.

    (To give some scale, after running the Evmos node for about a week, this single metric produced as many timeseries (~50k) as the rest of my infrastructure (20 or 30 hosts, tons of services, exporters, etc. etc.) did over 30 days 😲)

    edit: Sorry, it was actually 3 metrics:

    • evmosd_tx_msg_ethereum_tx_gas_limit_per_gas_used
    • evmosd_tx_msg_ethereum_tx_gas_used_total
    • evmosd_tx_msg_ethereum_tx_total
    pinned 
    opened by 08d2 9
  • fix: IBC withdraw middleware

    fix: IBC withdraw middleware

    Description

    Closes: #XXX


    All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.

    PR review checkboxes:

    I have...

    • [ ] added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] included the correct type prefix in the PR title
    • [ ] targeted the correct branch (see PR Targeting)
    • [ ] provided a link in the PR description to the relevant issue or specification
    • [ ] reviewed "Files changed" and left comments if necessary
    • [ ] confirmed all required CI checks have passed

    Code maintenance:

    I have...

    • [ ] written unit and integration tests
    • [ ] added relevant godoc and code comments.
    • [ ] updated relevant documentation (docs/) or specification (x/<module>/spec/)

    Reviewers Checklist

    All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.

    I have...

    • [ ] confirmed the correct type prefix in the PR title
    • [ ] confirmed all author checklist items have been addressed
    • [ ] confirmed that this PR does not change production code
    C:CLI 
    opened by fedekunze 9
Releases(v10.0.0-rc1)
Owner
Tharsis
Tharsis
Go implementation of Ethereum proof of stake

Prysm: An Ethereum Consensus Implementation Written in Go This is the core repository for Prysm, a Golang implementation of the Ethereum Consensus spe

Prysmatic Labs 2.9k Nov 18, 2022
A Verifyable Chain Relay for Proof of Stake Blockchains

A Verifyable Chain Relay for Proof of Stake Blockchains This repository contains

null 6 Nov 11, 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
A blockchains platform with high throughput, and blazing fast transactions

Node implementation for the Avalanche network - a blockchains platform with high throughput, and blazing fast transactions. Installation Avalanche is

null 1 Oct 31, 2021
Dijetsnetgo: a blockchains platform with high throughput, and blazing fast transactions

Node implementation for the Avalanche network - a blockchains platform with high

Dijets 0 Jan 18, 2022
An interoperable smart contract hub

Juno An interoperable smart contract hub which automatically executes, controls or documents a procedure of relevant events and actions according to t

Juno 248 Nov 17, 2022
ConsenSys Software 8 Jan 18, 2022
Pet-blockchain-go is a simple proof of work mining algorithm in Go.

pet-blockchain-go Pet-blockchain-go is a simple proof of work mining algorithm in Go. Inspired by: cosme12 / SimpleCoin nosequeldeebee / blockchain-tu

Max 1 Mar 10, 2022
Small utility to sign a small json containing basic kyc information. The key generated by it is fully compatible with cosmos based chains.

Testnet signer utility This utility generates a signed JSON-formatted ID to prove ownership of a key used to submit tx on the blockchain. This testnet

Archway Network 62 Sep 10, 2022
a Golang sdk for working with DeFi protocols, and ethereum compatible blockchains

A golang sdk for working with DeFi protocols and general utilities for working with ethereum-compatible blockchains. packages bclient bindings cli con

bonedaddy 72 Nov 11, 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
LEO (Low Ethereum Orbit) is an Ethereum Portal Network client.

LEO LEO (Low Ethereum Orbit) is an Ethereum Portal Network client. What makes LEO different from other Portal Network clients is that it uses libp2p f

Valist, Inc. 10 Apr 19, 2022
Ethereum-vanity-wallet - A fork of https://github.com/meehow/ethereum-vanity-wallet but the key can be exported to a JSON keystore file

ethereum-vanity-wallet See https://github.com/meehow/ethereum-vanity-wallet This version: doesn't display the private key let's you interactively expo

null 0 Jan 2, 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
This library aims to make it easier to interact with Ethereum through de Go programming language by adding a layer of abstraction through a new client on top of the go-ethereum library.

Simple ethereum client Simple ethereum client aims to make it easier for the developers to interact with Ethereum through a new layer of abstraction t

Jero 3 May 1, 2022
run ABI encoded data against the ethereum blockchain

Run EVM code against a database at a certain block height - Note You can't run this against a running geth node - because that would share the db and

Edgar Aroutiounian 60 Nov 11, 2021
Mini Blockchain Implementation In Golang Inspired by Go-Ethereum🚀

JP Blockchain ?? ?? Mini Blockchain Implementation In Golang Inspired by Go Ethereum & BlockChain Bar by Lukas (Web3Coach) Features Working Core Compo

Oren Leung 4 Aug 8, 2022
healthchecker monitors a liveness of various blockchain (e.g. Ethereum, Klaytn...etc)

healthchecker healthchecker monitors a liveness of various blockchain (e.g. Ethereum, Klaytn...etc) Quickstart Run server which listen to 8080 port: g

Daehyun Paik 0 Jan 23, 2022