In today's world, governments often grapple with outdated systems, making the introduction of innovative governance models a daunting task. These entrenched systems not only resist change but also harbor inherent flaws, such as the human alignment problem, where individual actions are driven by self-interest rather than the collective good. Historical events, like wars sparked by the selfish ambitions of leaders, underscore the dire consequences of misaligned governance. Futarchy, a concept proposed by economist Robin Hanson, has gained attention as an innovative governance model that combines democratic voting on values with betting markets on beliefs to decide policies. This model is based on the premise that betting markets are efficient at aggregating diverse information, making them potentially effective at predicting the outcomes of policies in terms of their impact on national welfare. The idea is that if a betting market clearly estimates a policy would increase expected national welfare, then that policy would be adopted. The concept of futarchy has not only been explored in academic discussions but has also been applied practically within blockchain and Decentralized Autonomous Organization (DAO) communities. These real-world applications test the principles of futarchy in various scenarios. For a more in-depth and scholarly examination of futarchy, Robin Hanson's paper "Shall We Vote on Values, But Bet on Beliefs?" is highly recommended. Additionally, a summary and critical analysis of Hanson's paper can provide valuable insights and takeaways from his proposal. How Futarchy Works Futarchy leverages the wisdom of the crowd through a betting mechanism aligned with the overarching goals of a community or organization. To illustrate, let's consider a community focused on enhancing residents' wellness. Step 0: Establish a Community Goalimage

Contributions to core development in Ethereum Project Abstract I worked on improving the Nimbus consensus client. Most of my workload throughout this fellowship has been dedicated to transitioning the block processing method to a model where blocks are fully indexed in memory, with the storage adopting an append-only file implementation. Project Proposal Status Report The initial plan centered around improving bip32, as proposed by Paul Miller. However, plans shifted, leading me to Nimbus-eth2 (An Ethereum Consensus Client in Nim). I had to learn the Nim programming language and understand the Ethereum Consensus. This project consisted of three major components:

Hey everyone, Just a quick rundown on what went down in Week 15. The real grind this time was tackling those persistent linking issues in the C WAL implementation. Took me a while, but I managed to sort it out. Had to part ways with some macros in the sqlite3.c file to get things back on track. Sometimes you've got to sacrifice a few things to make progress. Then there's Nim and the openArray[byte] datatype, throwing me a curveball. No beating around the bush, had to deal with it directly as a parameter in a proc to get it playing nice with the merkle patricia trie sample. One of those weeks Now, the ongoing saga with the ffi from C to Nim. Been using Nimterop, but it's been a bit of a headache. Dealing with a couple of clashes with variables, and progress has been slower than expected. It's a grind, to say the least.

Introduction In this eleventh update, I'll walk you through the challenges I encountered with the log-based implementation and the approach I've taken to overcome them. The Challenge I recently faced a hurdle while working on the WAL implementation. The issue was that the SQLite3 library I was using did not expose the functions required for independent use of the WAL implementation. This prompted me to explore alternative solutions. Exploring Possible Solutions In my pursuit of a solution, I brainstormed various possibilities. I'll reiterate the options I considered: Forking nim-sqlite3-abiThe idea here was to fork the nim-sqlite3-abi repository and manually add the necessary functions to the header file. However, this approach posed a concern. The vendor/nim-sqlite3-abi would have a new git pointer, which raised compatibility issues.

Introduction In the last update, I talked about my progress in understanding how blocks are processed. With guidance from Ethan at Status-IM, I was able to pinpoint the key function responsible for handling blocks: proc addResolvedHeadBlock in block_processor.nim. In this detailed update, we will delve deeper into this function and the components related to it. ChainDAG and Canonical Chains The focus of our exploration is the dag parameter, which is of type ChainDAGRef. ChainDAG is a critical concept in our blockchain processing. It initially stores a linear history of blocks, starting from the genesis block and extending to a certain point. Beyond this point, it allows for branching, creating a Directed Acyclic Graph (DAG) structure. Among these branches, one is considered the "canonical chain." This canonical chain represents the official and accepted history of the blockchain network. Branching and the selection of a canonical chain can occur due to factors like consensus forks. BeaconChainDB and Its Role Now, let's understand how everything fits together. One of the elements of type ChainDAGRef is BeaconChainDB, which is a vital part of our blockchain processing. block_clearance.nim - Line 60

This is my 9th update, and I'm pleased to share the progress I've made on the research for the log-based database implementation. As promised, I'll have a PR ready by the end of this month, and you can expect to see it in my 10th update. Now, let's delve into Nim, a language I find quite liberating. Nim grants you the freedom to work in your own way, which sets it apart from Go, a language I appreciate for its simplicity. However, Nim's flexibility and choice can be a double-edged sword. I've previously mentioned my struggle with the language server for the vscode-text-editor, but I've found a workaround by using two separate tabs. One tab is for quick function and type lookups that the language server would usually provide. Despite these challenges, Nim has been a rewarding experience overall. One notable drawback is the lack of documentation for certain types and functions in some libraries, likely due to the need for speedy development during the beacon implementation. Thankfully, there's a wealth of online resources to help fill in the gaps, and even ChatGPT has been a helpful source for grasping key concepts. While I'm confident in the majority of my design decisions, there are still some specific aspects I'm uncertain about. If you're following this development and find yourself struggling to grasp certain ideas, I recommend checking out this link. Although it primarily discusses libsql, a fork of SQLite, it provides valuable insights into concepts relevant to the Write-Ahead Logging (WAL) used in this project. As I move forward, the last hurdle (🤞) is deciphering how blocks are received within the codebase and determining the optimal approach to maintain consistency throughout the entire program.

This marks my 8th update on my current progress. I am working with the SQLite implementation of the write-ahead log, written in C, as a part of my solution. I've encountered several bottlenecks along the way. Initially, I faced challenges in acquiring the required 32 Goerli ETH because I wanted to run a goerli validator, and then I had some difficulties working effectively with the #cheap-goerli-eth. Additionally, I've found myself dealing with a multitude of new concepts simultaneously. While this journey has been a delightful learning experience thanks to the fellowship, I'm also mindful of my looming deadline. Transitioning from Go to Nim has been an interesting shift for me. Nim, though relatively simple to read, presents a rich set of features, making it somewhat like entering a foreign land compared to the simplicity of Go. Nevertheless, I appreciate the opportunity to explore these features as they've deepened my understanding of programming. Furthermore, I'm relatively new to the world of databases and consensus systems, but I'm thoroughly enjoying the learning curve that comes with them. It's been inspiring to witness active communication within the community, especially from individuals who have achieved significant accomplishments using Nim. It's indeed a wonderful environment to be a part of, and I truly cherish my passion for programming.

Week 6 Update: Taking Steps Forward This week, I made progress in getting ready to make the Nimbus Consensus Client better. Here's what I did: I started with reading the Ethereum Consensus specs. It helped me to understand the structure and where I'd be writing to my contribution of the append only database for Nimbus. It was easier to grasp, as the code styles to show functions where written in Python. Reading a Handbook: While implementation is on the way, I have started reading a book called "A Technical Handbook on Ethereum's Move to Proof of Stake and Beyond" by Ben Edgington. It's helping me understand the technical details of Ethereum's proof of stake. This is in preparation for the grand scheme of things, as I want to continue to improve on the consensus client. Digging into the Issue: I have spent time looking at the issue about log-based database for hot data. I have been able to learn more about how write-ahead log works and how it is fits to Nimbus project scope.

Week 5 - Update 6: Getting Ready to Dive In This week, I laid the foundation for my work on the Nimbus Consensus Client. Here's what I did: Talking with My Mentor: I had a good chat with my mentor, Zahary. We talked about the plan for the issues I'll be working on. He suggested I start by creating a new kind of database for the Nimbus beacon node. Learning: I went through some important stuff. I read the Nimbus style guide and the auditors' book for the Nimbus beacon node. I also kept up with the discussion about the new database idea on GitHub. Zahary explained some basic things to me. I also looked again at how the Nim programming language works, especially the way they use pragmas. I checked the rules in the Nim style guide again, so I remember the best way to write my code.

Introduction In this week's update, I will be discussing the recent developments in the project focus, building upon the topic I addressed in my previous update. Project Focus Shift As mentioned earlier, there has been a shift in the project focus, and I'm excited to share that this shift is already in progress. This update will provide insights into the direction the project is taking. Collaboration with Nimbus Team I've made significant strides in moving forward with the change in project focus. Specifically, I have engaged in productive discussions with Zahary from the Nimbus team. Our collaboration aims to kick-start efforts in extending Nimbus_eth2, the Ethereum 2 Beacon Chain written in the Nim programming language. Nim Proficiency

Encounter with Kev? In my previous update, I was eagerly anticipating a meeting with Kev. However, I must admit that this endeavor has not borne fruit thus far. The anticipated meetup did not exactly materialize. I have discussed the issues with Josh, and new suggestions have surfaced regarding potential mentors. While I'm awaiting the contact details of these suggested mentors, I'm gearing up to initiate contact and explore these alternative avenues. Exploring Nim During this interlude, I've dived into the world of Nim, a programming language that blends the familiar syntax of Python with the potential for low-level manipulations. The experience has been thoroughly engaging, allowing me to grasp various concepts with relative ease. Nim's unique amalgamation of features has indeed made for a stimulating learning experience. Observations from Fellow Fellows and the Nimbus Niche I took the time to read the development updates shared by my fellow participants. An interesting trend caught my attention: a considerable number of participants who are either aligned with Nim or are collaborating on projects proposed by Zahary of the Nimbus team seem to be gravitating towards the Verkle tree. It's intriguing to note that there appears to be less focus on the extended features projects of Nimbus_eth2. This observation has sparked an idea that might guide my future direction. The Allure of Nimbus Team's Openness and Hospitality

Introduction: The Complexities of Cryptographic Key Management Cryptographic key management remains a critical challenge in the realm of technology, and enhancing existing solutions like BIP32 holds immense promise. In the context of Ethereum, where my focus lies, the adoption of improved key management techniques could significantly impact the ecosystem. Understanding the Existing Landscape: BIP32 and Its Limitations To delve into this enhancement, a solid understanding of the original BIP32 specification is essential. This blueprint lays the foundation, yet it's clear that there's room for improvement. Let's highlight the reasons for this: Complex Parameter Handling: The reliance on multiple sources, such as SLIP-0044, to gather algorithm parameters. Derivation Complexity: The current derivation uses numerical indexes for protocol names, which must be taken from a separate document and does not specify a standard way to assign indexes. Inadequate Key Scheme: A more secure approach would involve limiting the scheme to hardened keys to mitigate security and privacy risks. Interoperability Concerns: The existing scheme's compatibility with non-secp curves is suboptimal.

Hello guys! Welcome to the second development update on my journey as an Ethereum Protocol Fellow. In this update, I will provide insights into the progress I've made on two significant projects: Improving bip32 hdkey (Nested Key Generation) and my exploration of the FHE-DKSAP (Fully Homomorphic Encryption - Dual Key Stealth Address Protocol) to enhance transaction anonymity. Additionally, I will touch upon my personal interest in learning Nim and my hobbyist exploration of the verkle tree during my fellowship. Part 1: Improving Bip32 HDKey (Nested Key Generation) 1.1 Understanding the Fundamentals I learnt the fundamentals of BIP32, which explains how master keys and master chain code are created from a BIP39 seed. Here is a rough image of my note showing a diagram of BIP32 Child Key Derivation (CKD) 1.2 Notes and Documentation I have maintained detailed notes throughout this research process, and these notes will be summarized and uploaded later in the week to the notes directory within the cohort-four repository. 1.3 Specification for Implementation

The purpose of this report is to outline the selection process for the project I have chosen to pursue as a fellow. My name is Gbolahan, and my area of focus is Cryptography. In this report, I will discuss the projects considered for the fellowship and explain why I eventually chose the specific project. Projects Considered During the exploration phase, several project ideas were considered. Two notable projects in the project ideas suggested by mentors that caught my attention were: Help Solve Practical Challenges with SSLE by DappLion: This project idea aimed to address practical challenges with Secret Single Leader Election (SSLE). Although it aligned with the field of cryptography, it lacked detailed information and discussions, making it difficult to evaluate its potential. The project's timeline in relation to the Ethereum roadmap also raised concerns. However, further investigation is still ongoing. Nim Projects by Zahary: The Nim projects suggested by Zahary presented an interesting opportunity. Although unfamiliar with Nim, the clear and concise project suggestions, particularly the Verkle tree library, sparked interest. Learning Nim was considered a feasible option due to ample learning resources available in the Nim documentation.