Go Ethereum

Open-source Go projects categorized as Ethereum

Top 23 Go Ethereum Projects

  • go-ethereum

    Go implementation of the Ethereum protocol

  • Project mention: Ethereum Foundation removes their canary | news.ycombinator.com | 2024-03-20

    Even more relevant would be the Ethereum Improvement Proposal repo (where people submit proposals to change the spec):

    https://github.com/ethereum/EIPs

    Or the go-ethereum execution client (the most popular execution client):

    https://github.com/ethereum/go-ethereum

    Project mention: Best Crypto To Invest in 2024 [Expert Guide] | dev.to | 2023-12-29

    Chainlink (LINK) – The Blockchain Oracle Giant

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • optimism

    Optimism is Ethereum, scaled.

  • quorum

    A permissioned implementation of Ethereum supporting data privacy

  • prysm

    Go implementation of Ethereum proof of stake

  • Project mention: Did I break CURL ? can't update my validator from github | /r/ethstaker | 2023-07-22

    curl -LO https://github.com/prysmaticlabs/prysm/releases/download/v4.0.7/beacon-chain-v4.0.7-modern-linux-amd64

  • awesome-blockchain

    ⚡️Curated list of resources for the development and applications of blockchain.

  • turbo-geth

    Ethereum implementation on the efficiency frontier

  • Project mention: AMD EPYC 7C13 Is a Surprisingly Cheap and Good CPU | news.ycombinator.com | 2024-03-27

    To be clear, it was a CPU fault that doesn't occur at all when running e.g. stress-ng, but only (as far as I know) when running our particular production workload.

    And only after several hours of running our production workload.

    But then, once it's known to be provokeable for a given machine, it's extremely reliable to trigger it again — in that it seems to take the same number of executed instructions that utilize the faulty part of the die, since power on. (I.e. if I run a workload that's 50% AES-NI and 50% something else, then it takes exactly twice as long to fault as if the workload was 100% AES-NI.)

    And it isn't provoked any more quickly, by having just provoked it with the last hard-fault — i.e. there's no temporal locality to it. Which would make both "environmental conditions" and "CPU is overheating / overvolting" much less likely as contributing factors.

    > There have been enough of them in private hands for long enough that if there were widespread issues they would be well-known.

    Our setup is likely a bit unusual. These machines that experienced the faults, have every available PCIe lane (other than the few given to the NIC) dedicated to NVMe; where we've got the NVMe sticks stuck together in software RAIDO (meaning that every disk read fans in as many almost-precisely-parallel PCIe packets contending for bus time to DMA their way back into the kernel BIO buffers.) On top of this, we then have every core saturated with parallel CPU-bottlenecked activity, with a heavy focus on these AES-NI instructions; and a high level of rapid allocation/dellocation of multi-GB per-client working arenas, contending against a very large and very hot disk page cache.

    I'll put it like this: some of these machines are "real-time OLAP" DB (Postgres) servers. And under load, our PG transactions sit in WAIT_LWLOCK waiting to start up, because they're actually contending over acquiring reader access to the global in-memory pg_locks table in order to write their per-table READ_SHARED locks there (in turn because they're dealing with wide joins across N tables in M schemas where each table has hundreds of partitions and the query is an aggregate so no constraint-exclusion can be used.) Imagine the TLB havoc going on, as those forked-off query workers fight for time.

    It's to the point that if we don't either terminate our long-lived client connections (even when not idle), or restart our PG servers at least once a month, we actually see per-backend resource leaks that eventually cause PG to get OOMed!

    The machines that aren't DB servers, meanwhile — but are still set up the same on an OS level — are blockchain nodes, running https://github.com/ledgerwatch/erigon, which likes to do its syncing work in big batches: download N blocks, then execute N blocks, then index N blocks. The part that reliably causes the faults is "hashing N blocks", for sufficiently large values of N that you only ever really hit during a backfill sync, not live sync.

    In neither case would I expect many others to have hit on just the right combination of load to end up with the same problems.

    (Which is why I don't really believe that whatever problem AMD might have seen, is related to this one. This seems more like a single-batch production error than anything, where OVH happened to acquire multiple CPUs from that single batch.)

    > It's possible that AMD didn't order enough capacity from TSMC to meet demand, and couldn't get more during the COVID supply chain issues.

    Yes, but that doesn't explain why they weren't able to ramp up production at any point in the last four years. Even now, there are still likely some smaller hosts that would like to buy EPYC 7xxxs at more-affordable prices, if AMD would make them.

    You need an additional factor to explain this lack of ramp-up post-COVID; and to explain why the cloud providers aren't still buying any 7xxxs (which they would normally do, to satisfy legacy clients who want to replicate their exact setup across more AZs/regions.) Server CPUs don't normally have 2-year purchase commitments. It's normally more like 6.

    Sure, maybe Zen4c was super-marketable to the clouds' customers, so they negotiated with AMD to drop all their existing spend commitments on 7xxx parts purchases in favor of committing to 9xxx parts purchases. (But why would AMD agree to that, without anything the clouds could hold over their head? It would mean shutting down many of the 7xxx production lines early, translating to the CapEx for those production lines not getting paid off!)

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
  • bsc

    A BNB Smart Chain client based on the go-ethereum fork

  • Project mention: BSC Hardfork 12th JUNE ! | /r/bsc_private_full_node | 2023-06-10
  • evmos

    Evmos is the first decentralized EVM chain on the Cosmos Network. It's implementing the first EVM stack focused on native, cross-chain applications. Evmos is the flagship implementation of Ethermint, an EVM library built for the Cosmos Network by the Evmos Core Developement Team.

  • Project mention: Guide to Setting Up Evmos CLI for ERC20 to IBC Token Conversion | /r/EVMOS | 2023-11-24

    Go to Evmos Releases on GitHub.

  • bee

    Bee is a Swarm client implemented in Go. It’s the basic building block for the Swarm network: a private; decentralized; and self-sustaining network for permissionless publishing and access to your (application) data.

  • Project mention: Monthly Development Update – April 2023 | /r/ethswarm | 2023-05-25

    Deployed Bee to the mainnet (v1.14.1).

  • open-ethereum-pool

    Open Ethereum Mining Pool

  • mev-boost

    MEV-Boost allows Ethereum validators to source high-MEV blocks from a competitive builder marketplace

  • Project mention: mevboost proposal error | /r/ethstaker | 2023-07-07
  • trueblocks-core

    The main repository for the TrueBlocks system

  • Project mention: How to store large amounts of blockchain data for analysis and low-latency querying? | /r/dataengineering | 2023-06-03

    search for trueblocks https://github.com/TrueBlocks/trueblocks-core

  • polygon-edge

    A Framework for Building Ethereum-compatible Blockchain Networks

  • Project mention: Where can i find the instruction for installing Polygon 0.6.2 ? | /r/polygonnetwork | 2023-06-19

    I can find the github repo here : https://github.com/0xPolygon/polygon-edge/tree/v0.6.2

  • bor

    Official repository for the Polygon Blockchain

  • Project mention: Best Crypto To Invest in 2024 [Expert Guide] | dev.to | 2023-12-29

    Polygon (MATIC) – Scaling Ethereum Today

  • status-go

    The Status module that consumes go-ethereum

  • go-livepeer

    Official Go implementation of the Livepeer protocol

  • firefly

    Hyperledger FireFly is the first open source Supernode: a complete stack for enterprises to build and scale secure Web3 applications. The FireFly API for digital assets, data flows, and blockchain transactions makes it radically faster to build production-ready apps on popular chains and protocols. (by hyperledger)

  • ethgo

    Ethereum Golang API

  • mev-boost-relay

    MEV-Boost Relay for Ethereum proposer/builder separation (PBS)

  • Project mention: Missed proposal (couldn't submit blinded block). Just a mev relay issue? | /r/ethstaker | 2023-06-11

    time="2023-06-11T19:51:35-04:00" level=info msg="best bid" blockHash=0xf2bd4f24d68a792c88cb5f885a5cd1682662fe26c0e0eb9e8b274e586df16681 blockNumber=17460239 method=getHeader parentHash=0x03beefa5530f40cec9c00119309838f5d3e82c007e1c98cc179ed269929a0f77 pubkey=0xa96f35d5a9d94d844e320ac284f7d86d9c5a238f7a1695bd7940290e6d964c11b8527763344b144d4e3f38a32f23c0ae relays="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net" slot=6641956 txRoot=0x63337111b810cd01e1ca5d9676831cc08c6da778ec1b9b462131efed5dd7b203 value=0.248591416663511916 version=v1.5.0 time="2023-06-11T19:51:35-04:00" level=info msg="http: GET /eth/v1/builder/header/6641956/0x03beefa5530f40cec9c00119309838f5d3e82c007e1c98cc179ed269929a0f77/0xa96f35d5a9d94d844e320ac284f7d86d9c5a238f7a1695bd7940290e6d964c11b8527763344b144d4e3f38a32f23c0ae 200" duration=0.147492 method=GET path=/eth/v1/builder/header/6641956/0x03beefa5530f40cec9c00119309838f5d3e82c007e1c98cc179ed269929a0f77/0xa96f35d5a9d94d844e320ac284f7d86d9c5a238f7a1695bd7940290e6d964c11b8527763344b144d4e3f38a32f23c0ae status=200 version=v1.5.0 time="2023-06-11T19:51:44-04:00" level=warning msg="error making request to relay, retrying" blockHash=0xf2bd4f24d68a792c88cb5f885a5cd1682662fe26c0e0eb9e8b274e586df16681 error="HTTP error response: 400 / {\"code\":400,\"message\":\"sent too late - 9234 ms into slot\"}\n" method=getPayload parentHash=0x03beefa5530f40cec9c00119309838f5d3e82c007e1c98cc179ed269929a0f77 slot=6641956 url="https://boost-relay.flashbots.net/eth/v1/builder/blinded_blocks" version=v1.5.0

  • core

    Decentralized Fog Computing Platform (by sonm-io)

  • atomic-swap

    💫 ETH-XMR atomic swap implementation

  • Project mention: MAGIC Monero Fund 2024 Election - If you would like to contribute to an organization that funds R&D and educational outreach for Monero consider participating as a voter or a committee member! | /r/CryptoCurrency | 2023-12-07
  • snowbridge

    A trustless bridge between Polkadot and Ethereum

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    SaaSHub logo
NOTE: The open source projects on this list are ordered by number of github stars. The number of mentions indicates repo mentiontions in the last 12 Months or since we started tracking (Dec 2020).

Go Ethereum related posts

Index

What are some of the best open-source Ethereum projects in Go? This list will help you:

Project Stars
1 go-ethereum 46,063
2 chainlink 6,581
3 optimism 5,058
4 quorum 4,586
5 prysm 3,348
6 awesome-blockchain 3,058
7 turbo-geth 2,938
8 bsc 2,582
9 evmos 1,623
10 bee 1,435
11 open-ethereum-pool 1,367
12 mev-boost 1,075
13 trueblocks-core 1,021
14 polygon-edge 960
15 bor 954
16 status-go 715
17 go-livepeer 527
18 firefly 471
19 ethgo 453
20 mev-boost-relay 395
21 core 358
22 atomic-swap 333
23 snowbridge 273

Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com