BullShark is a protocol that achieves Byzantine Atomic Broadcast (BAB) in a distributed system using a DAG. It lies in the DAG-Rider paradigm, optimized for the common synchronous case, and entails several main enhancements to ensure practical deployability. The core idea is to use the DAG to order transactions in a distributed Byzantine setting, and it gives a sound solution toward distributed consensus for deploying blockchain technologies. BullShark runs on a peer-to-peer message-passing model, where each message is a vertex in the DAG. The key primitive assumes a computationally bounded adversary who is allowed to corrupt at most a third of the parties. The notion of reliable link between honest parties means that all messages eventually arrive, which is what supports the operation of the protocol both in synchronous and asynchronous periods. The work adopts a GST model to be able to reason about synchronous network conditions. BullShark Core: DAG Constructions The protocol has a DAG construction at its core. Each party posts transaction proposals through messages into a DAG. In the DAG, vertices represent messages, and edges represent causal relationships. The parties make a new vertex through combining blocks of transactions and with references to messages which it has previously received. These references are either strong, hence link to vertices in the previous round, or weak, hence link to vertices in rounds which are earlier to ensure their eventual inclusion in the total order. BullShark relies on reliable broadcast mechanisms to give firm guarantees of message integrity, agreement, and validity among parties with the fact that all honest parties will eventually receive the same messages and have a consistent view of the DAG. The protocol further makes use of a global perfect coin for leader election and is charged with leaders who possess fairness and unpredictability in terms of leadership selections for message proposals. Advancing rounds in BullShark The protocol is built itself around certain conditions that drive the process of advancement. By feeding a round with enough vertices, specifically 2 f + 1, parties ensure advancement into the next. Advancing is guaranteed even when messages in the middle of the process of reaching another party are delayed. During synchronous periods, BullShark introduces timeouts to bound the round advancement protocol, and this dual approach gives the best of both worlds: very low latency and high throughput yet with liveness guarantee under worst-case asynchronous conditions

https://github.com/kingstone888/hypepool https://github.com/xiaolin1579/miningcore https://github.com/pool2mine/miningcore https://ethereumclassic.org/why-classic https://miningpoolhub.com/ https://ethereum-classic.miningpoolhub.com/ https://github.com/zone117x/node-open-mining-portal https://github.com/etclabscore/core-geth https://etclabscore.github.io/core-geth/ https://github.com/etclabscore/open-etc-pool

References https://www.paradigm.xyz/2022/07/consensus-throughput https://www.paradigm.xyz/2022/07/experiment-narwhal-bullshark-cosmos-stack https://decentralizedthoughts.github.io/2022-06-28-DAG-meets-BFT/ Narwhal and Bullshark: DAG-based Mempool and Efficient BFT Consensus - https://www.youtube.com/watch?v=xKDDuPrYUag Consensus days - https://www.youtube.com/playlist?list=PLhuBigpl7lqsq-WnYIHmds7oSqULOQU4x Mysticeti - https://www.youtube.com/watch?v=wRXhxB0mR8Y Shoal - https://www.youtube.com/watch?v=Ne0opDqzn6Y DAG Meets BFT: The Next Generation of BFT Consensus with Alexander Spiegelman | a16z crypto research - https://youtube.com/watch?v=NGOXVSFzYdI MEV Resistance on a DAG - https://blog.chain.link/mev-resistance-on-a-dag/

Having my own hardware to solo stake and setup a node for development and research purpose has always been in my heart Huge thanks to EthStaker for the lil push that I was hesitant to make to and supporting me reimbursing my hardware cost (not done yet! after 2 months of mainnet DVT staking). The most exciting and intriguing thing I feel is that I am able to contribute to the ethereum network from this small piece of hardware kept in a corner of my hostel room at my uni. Its very likely that I am the only one in my college with a node running :) Many people dont know but EthStaker community is a gem! The discord is filled with staking experts. Their docs is the best consolidated resource - https://docs.ethstaker.cc/ethstaker-knowledge-base/

Why Decentralized Sequencers? Single point of failure: if the centralized operator goes down the whole network is affected; liveness concern Censorship prone Centralization of MEV extraction Why Shared Sequencer? Interoperability between apps across rollups is limited Can't have single tx that updates multiple rollup states at once (atomic execution) atomic inclusion?

By: Naman Garg (2021171) Instructor: Dr. Dhruv Kumar Introduction As the web3 technology moves towards wide-spread adoption, it is necessary to ensure that users are comfortably able to use the applications. To serve the next billion users it is necessary to ensure we can provide web2-like experience to the web3 users. Enter intents - if a transaction refers to "how" an action should be performed, an intent refers to "what" the desired outcome of the action should be [1]. This declarative approach opens the door to increased efficiency and user experience. Users can simply express their desired result, leaving it to knowledgeable third parties (solvers) to figure out how to best achieve it. The imperative paradigm today, in which the user actively specifies every parameter, is in contrast.

The cohort 4 of EPF has finally ended and I can say I had the best experience during these months! Verkle Implementation in Nim Project Proposal Project Presentation Slides Devconnect Presentation Reference Implementation :Go Verkle Verkle Trie Reference (Python) Project Repository :

A list of projects and proposals for decentralized and shared sequencing. Projects Note: the maturity of these projects varies, and the documentation is usually not great. AltLayer Beacon Layer AstriaAstria Development Cluster (Anoma) Chimera Chains

Verkle Trie Besu This week I majorly worked on implementing the removeVisitor function. In besu (bonsai) the rollback feature was needed i.e. rolling back to the previous state therefore the deletion of values has to be done, though deletion is not actually a part of Verkle trie. I got my PR merjed - feat: add RemoveVisitor and unit tests Implementation is close to completion only Pederson commitments are left 🚀 Other Got my PR merged in the lambda ethereum consensus in elixir - feat: add Metadata SSZ container + unit test (Thanks to Michael, consensus caught my interest)

In the weekly meeting I discussed about the database layer of Nimbus. Zahary shared that they are going to change to a db which a flat database (similar to besu) and has very good performance so integrating verkle trie should not be a problem. After getting the updates from everyone - seems like we are close to the completion. Nim trie + Rust Crypto Now to do comparative testing I will import the Rust libraries used for commitments into our project. This is going to be very tricky (not even sure if it would work). Different tests has shown that rust cryptography is defineatly slower but since we have to do the comparative testing taking into account the trie we will have to integrate it. Todo

Gm everyone! I am working on Verkle tree implementation for the Nimbus client. Development Updates I had a meet with Dragan and Thomas (they are working on verkles for besu) and discussed various things related to verkles. Its always nice to talk to someone working on the same topic - you get good insights and their perspective which helps in better understanding :) Also we need to look in the nimbus client database layer which was also suggested by Gballet. We discussed this in the weekly meet and Daniel referred someone from Nimbus who would be the best person to talk to regarding this. deleteValue operation got merged in the nim-eth-verkle repo Made a draft PR to add helper functions, error handling and tests to the same.

Gm everyone! I am working on Verkle tree implementation for the Nimbus client. I talked with Mario and he helped me realize that contributing to Nimbus and Besu both might be too much work and focusing on one of them will be better idea and keeping the other for later, which I completely agree with so I am focusing on Nim implementation first. Research Reading and understanding about the verkle tree structure: I read this in the starting weeks also and thought I understood but when now I started to code, I started getting a lot of doubts. The major reason for this was because it is difficult to visualize verkle tree operations - there is no tool for this. Real-world test: I researched on solving this issue and discussed the possibilities and its importance with Daniel, Gballet and Jsign, and concluded this Weekly Meeting with Nimbus This weekly meeting was really informative. Agnish, Advaita discussed a lot of cryptographic stuff with Mamy and I also catched a lot of things from their discussion.

Gm everyone! I am working on writing and improving the tests for the Verkle Trees library for the Nimbus and Besu client. Deep dived in tree.go, tree_test.go. Assigned myself this issue to write similar tests for nimbus verkle trie. I assigned myself this issue to write tests for Pederson Commitments and Update Commitments in Java. Will be mainly working on completing this for the coming week. Weekly Meetings Update Nimbus Client

Gm everyone! I will be working on improving the testing and doing the comparative tests of the verkle trees library. Description Once the Verkle implementation is done we'll want to run various tests to compare it to other implementations. I noticed the rust library did a nice fuzzing test, using a deterministic RNG. We could do the same (in Nim) using the same RNG and compare our results to theirs. The fuzzing test is currently a bit basic, it just generates key/values and adds them to the tree. We will enhance it to generate sparse/dense/deep trees to better test edge cases. Also, we could enhance it to perform additional actions on the tree, like deleting and fetching keys, or computing commitments and verifying proofs for random keys (i.e. each node down from the root) or batches of keys. This would test for caching issues (we'll be caching commitments), and could also serve for benchmarking. It would also be nice to contribute back the extended test suite to the Rust and Go implementations, so we can compare the implmentations, and to help them debug their own. RnD Go implementation of Verkles Inner Product Arguements

I have finally decided to go with Verkle Trees for my project. I am still thinking between Nim or Java implementation of it. I got in touch with Nimbus team and the OnlyDust team (for java) to know the current progress and how I can contribute. Also I read the updates from other fellows working on verkle trees and they were quite useful. Readings Verkle Transition The state of statelessness Nim lang And many other great readings are present here Verkle trees info page

Another week full of learnings. I realized that I narrowed myself to a single topic too soon, rather I should explore other project topics as well and understand ethereum protocol as a whole. RnD Go ethereum - referred to the book and video Learnt Go basics through YT Verkle tree - what are verkle trees and jsing notes EIP 4488 specs Poseidon hash function Single slot finality (in early stage so droped but its interesting) Danksharding

Introduction First of all - very excited to take part in this cohort. Goal is to learn as much as I can by working on a good advance project and build my way up. Exploring projects The first step is to try find the project which I want to work on. So I went through the given project ideas and there were particulary 2 ideas that caught my interest - Ephemery Testnet - By Mario Havel ERC-4337 tooling support - By Yoav Weiss I went ahead with the Ephemery testnet idea because it was something new to me and more cool.