
An active Player in the game of technology


Brian Baliach


Recently, I was asked to present on Domain Driven Design. As I delved deeper into the research, it became clear that DDD is a crucial aspect of system architecture that many developers don’t fully grasp.

Building software that aligns with complex business needs can be daunting, especially as systems grow in complexity. Domain Driven Design (DDD) offers a methodology that addresses this challenge by focusing on the business domain and its logic, thereby enabling developers to create systems that fulfill real-world business requirements.

#### What is Domain Driven Design?

**Domain Driven Design** is a software development approach that focuses on the core business domain and its logic over technological aspects. It involves creating a semantic model that mirrors real-world scenarios. This approach ensures that software components are named in a way that reflects how domain experts and stakeholders discuss the business.

Imagine a fintech company developing a loan management system. By adopting DDD, the development team creates classes like `LoanApplication`, `LoanApproval`, and `RepaymentPlan`. This makes the software model understandable to financial experts within the company, facilitating better collaboration and reducing miscommunication.

DDD therefore enhances the effectiveness of software development by aligning it more closely with business needs. By concentrating on the business’s core processes and rules, DDD ensures that the developed software is more adaptable to changing business requirements and continues to solve relevant problems.


Remember, Domain Driven Design isn't just about complex coding solutions; it's about fostering a collaborative environment where software directly solves business problems. An e-commerce platform may define a `Customer` and a `Guest User` and understanding the domain well means recognizing the difference between a `Customer` and a `Guest User`. Naming conventions like these ensure that all team members are on the same page, ultimately leading to a more cohesive and functional system.

#### Key Principles of Domain Driven Design
For this section, I'll attempt to use real world examples to better support my explanations.

1. **Ubiquitous Language**:
   Ubiquitous Language is a common language crafted by the team, including developers and domain experts. It ensures that all terms and phrases are clearly understood in the business context, eliminating ambiguities.

   **Real-World Example**: In a logistics company, terms like `Carrier`, `Shipment`, and `Delivery` are clearly defined. When developers and logistics experts use the same terminology, implementing a feature like `ShipmentTracking` becomes straightforward and error-free.

2. **Model-Driven Design**:
   This principle involves creating a conceptual model outlining all key elements of the domain, which acts as a blueprint. The model evolves over time, being continually refined to better match the domain complexities. For instance, if your domain includes entities like 'Buyer' and 'Farmer', you need to meticulously define their attributes and interactions, such as an 'Admin' entity that can 'Create User', 'Create Cash Credit Product', or 'Send Bulk SMS'.

   **Real-World Example**: In a healthcare application, entities such as `Patient`, `Doctor`, `Appointment`, and `Prescription` are modeled.A `Patient` creates an `Appointment`.  A `Doctor` treats a `Patient`. A `Patient` is given a `Prescription`.

3. **Context Boundaries (Bounded Context)**:
   Bounded Context defines clear boundaries around a particular domain model or subsystem, enabling teams to work independently without interfering with each other. For instance, in the given domain, only Admins can create cash credit products, and while Admins can create Buyers, Buyers can also register or onboard themselves.

   **Real-World Example**: In a banking application, separate bounded contexts for `Account Management` and `Loan Processing` ensure that teams working on these features do not step on each other's toes. Account management can evolve independently from loan processing.

#### Core Building Blocks of DDD

1. **Entities**:
   Entities are objects with a distinct identity that persists over time. An example is a Farmer named 'Melvin', who has a unique ID within the system.

2. **Value Objects**:
   Value Objects are defined by their attributes and are immutable. For example, a Farmer can have attributes like 'Name' and 'ID', which are value objects.

3. **Aggregates**:
   An Aggregate is a cluster of entities and value objects treated as a single unit for data changes. Each aggregate has a root entity controlling access. For example, a Farmer can be an aggregate root and may include other entities like 'Cash Credit'.

4. **Domain Events**:
   These are significant business events that trigger changes within the domain, such as placing an order or initiating bulk payments. They help decouple systems and model real-world operations.

5. **Repositories**:
   Repositories are responsible for the persistence and retrieval of aggregates, abstracting the inner workings of data access mechanisms.

#### Common Challenges in Implementing DDD

1. **Complexity in Execution**:
   Implementing DDD can seem overwhelming due to its deep modeling and upfront design focusing on domain intricacies. Starting with a critical subdomain and gradually expanding can help manage this complexity. As an example, a business building a Health Management System may start off first with patient onboarding, before moving to other sections like doctor onboarding.

2. **Integration with Non-DDD Systems**:
   Non-DDD systems might behave differently, posing challenges in maintaining data and behavior consistency. Using anti-corruption layers or dedicated interface contexts can mitigate these issues. An e-commerce platform might use API gateways to bridge legacy inventory systems with the new DDD-based application.

3. **Under- or Over-Modeling**:
   There is a risk of either over-complicating or oversimplifying the model, missing essential complexities. Regular reviews with domain experts and iterative refinement help maintain balance.

4. **Adoption and Cultural Shifts**:
   DDD requires a cultural shift towards collaboration and a strong focus on the domain. Investing in training and workshops can enhance understanding and facilitate this transition.

#### Best Practices for Domain Driven Design

1. **Collaboration Between Domain Experts and Developers**:
   Deep collaboration between business experts and developers is essential. Regular interactive sessions help refine the domain model effectively.

2. **Continuous Learning and Context Evolution**:
   The business domain evolves over time; thus, the domain model should too. Establish feedback mechanisms like retrospective meetings and model storming sessions.

3. **Keep the Model and Implementation Aligned**:
   Changes in the domain model must be reflected in the implementation. Using domain and integration events can ensure consistency.

4. **Iterative Refinement**:
   The domain model should be a living document, continuously refined based on real-world feedback and testing.

5. **Explicitly Define Context Boundaries**:
   Clear boundaries help prevent inappropriate coupling and complexity. Well-defined APIs, schemas, and contracts can manage interactions between contexts.

#### Tools and Frameworks for DDD

Technology plays a crucial role in implementing DDD effectively. Popular frameworks like NextJS, NextJS, .Net and Java Spring help build complex software systems, while modeling tools like UML diagrams and class diagrams help visualize complex domain models. For practical application, projects like Digifarm (where I'm currently employed, and the birth of this blog post) can illustrate these concepts in action.

#### Conclusion and Q&A

Effectively implementing Domain Driven Design involves more than just a technical shift; it requires a cultural transformation within development teams. This transformation fosters closer collaboration between domain experts and developers, ensuring that the software built truly serves the business objectives. By embracing DDD, organizations can create adaptable, business-aligned software capable of evolving as business needs change.

If you have any questions about DDD, feel free to ask! Whether you're curious about specific principles or need advice on tackling common challenges, I'm here to help. Stay curious!


Introduction to Domain Driven Design: Bridging the Gap Between Complex Systems and Software


Hello once again my fellow code-based creature enthusiasts!

Have you ever felt that managing pull requests can feel like navigating a complex, never-ending labyrinth where each
exit only leads to another room filled with code rather than a solution? Well, if you are nodding along or sighing
dramatically, we are about to dive deep into a pool of AI-driven pull request management tools. Buckle up, as we pit our
open-source underdog, CodiumAI's PR-Agent, against the reigning heavyweight, GitHub Copilot.

Now, just to be honest and clear: PR reviews can be as nerve-wracking (or more) as defusing an oddly colored blue-wired
bomb - under the camera of a Nokia Simens phone (for those born later, a 1MP camera). But fear not, CodiumAI to the
rescue to ensure PR reviews instead feel like a breezy walk at a picturesque park, or a quick, efficient jog if you're
in Kenya and feel so inclined. In the world of GitHub, which usually is the mecca for the developers, PR-Agent swaggers
in like a strong contender.

Itchy to know more? Scroll away!

### Opening Act - What is Github Copilot and Codium's PR-Agent?

GitHub Copilot and Codium's PR-Agent are two powerful tools designed to assist developers and streamline their coding
process.

GitHub Copilot, powered by OpenAI, essentially acts as an AI pair programmer. It leverages the knowledge of billions of
publicly available code snippets to suggest completions and generate code based on the context of your work. So, while
working on a task, it may suggest potential implementations for functions, write new code, aid in implementing best
practices, and even speed up the process of writing repetitive or boilerplate code.

On the other hand, Codium's PR-Agent is a highly capable, open-source tool designed to tackle the challenge of reviewing
pull requests efficiently. It's equipped with an impressive set of commands making pull request management a smoother
ride. With features like automated PR description generation, review feedback, question answering, code suggestions,
changelog updates, similarity check with other issues, documentation addition, and custom label generation, it gives you
much more direct control over your PR reviews.

While GitHub Copilot lends a helpful hand during the coding phase, Codium's PR-Agent steps up the game during the often
overlooked, but crucial, code reviewing process. Imagine being able to instantly describe a pull request, give immediate
feedback, improve your codes, update your changelogs, finding similar issues, generate documentation, and even creating
custom labels all with simple commands. It offers a sophisticated suite of tools that enhance your code reviewing
capabilities, making it simpler, faster, and so much more efficient. No hidden subscription fees or any
obligations. What’s not to love?

So, while GitHub Copilot serves as your sidekick while coding, Codium's PR-Agent ensures your pull requests are of the
highest quality, making it an indispensable ally in your coding workflow.

### The Ins and Outs of CodiumAI's PR-Agent

It is famously said that heavy is the crown worn by the king. In the programming world, the crown often goes to
customization as the king. CodiumAI's PR-Agent understands this better than most. It lets you tweak settings with
developer-level precision, the kind you'd want in your personal relationships, but we will stay within safe limits on
that one.

Ever wanted a software helper who's palms you can grease to sometimes look the other way during your code analysis? Just
drop in an easy `ignore.toml`. PR-Agent looks the other way, no questions asked. Just pop `ignore.toml` in and make
PR-Agent ignore certain files.

But wait, there's more.

Let's take a detailed journey about how CodiumAI's PR-Agent fits in your project, by creating a hypothetical scenario
and walking through the process.

## An Illustrated Walkthrough With CodiumAI's PR-Agent

The scenario:

Imagine we have a simple React app that uses Chakra-UI, with a couple of pages -- Login.jsx and Register.jsx. We will
work with our local repo and install CodiumAI's pr-agent as per instructions
provided [here](https://github.com/Codium-ai/pr-agent/blob/main/INSTALL.md#run-from-source).

_(Disclaimer: No actual code was harmed in writing this post)_

Here’s a quick overview of the steps to follow (assuming that you've at least gotten as far as cloning the repo):

- Navigate to the repo folder that you've just cloned:

  ```bash
  cd pr-agent
  ```

- We create a Python virtual environment before running pip install:

  ```bash
  python3 -m venv venv
  ```

- Next, set up an account on [Pinecone](https://www.pinecone.io/), a vector database required by Codium. After logging
  in, copy your API key from the 'API Keys' section or create a new key.
- Then, edit `pr_agent/settings/.settings.toml`. If it doesn't exist, create it using the following commands:
  ```bash
  cp pr_agent/settings/.secrets_template.toml pr_agent/settings/.secrets.toml
  ```

Since you might end-up running into errors when trying to run the pr-agent locally (this is because the '.secrets.toml'
file contains all possible entries, including optional ones uncommented) just use my settings.toml which has been
cleaned up:

```bash
# QUICKSTART:
# Copy this file to .secrets.toml in the same folder.
# The minimum workable settings - set openai.key to your API key.
# Set github.deployment_type to "user" and github.user_token to your GitHub personal access token.
# This will allow you to run the CLI scripts in the scripts/ folder and the github_polling server.
#
# See README for details about GitHub App deployment.

[openai]
key = "<your openai api key here>"  # Acquire through https://platform.openai.com

[pinecone]
api_key = "f8fc9404-e934-43fd-8dcc-11f51d4387a8"
environment = "gcp-starter"

[github]
# ---- Set the following only for deployment type == "user"
user_token = "<your github personal access token here>"  # A GitHub personal access token with 'repo' scope.
deployment_type = "user" #set to user by default
```

That's everything to do with installing Codium's pr-agent by building from source. Now onto the repo with our
hypothetical scenario. [Clone this repo](https://github.com/TylerMutai/codium-pr-agent-react-example.git) to efficiently
follow along.
Then run the usual within the repo's folder:

```bash
npm i
```

- We then branch out for our new feature

```bash
git checkout -b feature/hebrew-lang-support-with-rtl
```

At this point, we assume the feature is already built.
Here's [the commit listing all changes.](https://github.com/TylerMutai/codium-pr-agent-react-example/commit/d65634acce251a82d33e6dea5168009c22942ecf)

And then push our code to our branch.

```bash
git add .
git commit -m "added hebrew language support and rtl support"
git push -u origin feature/hebrew-lang-support-with-rtl
```

Next, create a PR using the provided link in the response message.

With that done, let’s say we are introducing a new feature for Hebrew language support with RTL. With PR-Agent in our
toolkit, we are ready to tackle it head-on.

First things first, we want to test our CodiumAI's PR-Agent. To do that, navigate back to the directory you cloned your
pr-agent in (which was covered earlier in this blog):

```bash
cd pr-agent
```

We then activate python's virtual environment:

```bash
source venv/bin/activate
```

We use the `reflect` command that generates some interesting queries:

```bash
python -m pr_agent.cli --pr_url=https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1  reflect
```

Voila! You get a response, automatically pushed to the PR as comments under your user. PR-Agents infers significant
changes to the code and highlights them, saving us from a deep dive directly into the 'files changed' tab (_cough_
senior developers _cough_).

Here's a snippet of the response (view it in
full [here](https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1#issuecomment-1838951359)):

![reflect-codium-pr-agent.png](/images/posts/reflect-codium-pr-agent.png)

---

Feeling adventurous, we let AI take the wheel a bit more and asked it to show us possible improvements or changes that
can be made to our PR using the `ask` command:

```bash
python3 -m pr_agent.cli --pr_url=https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1 ask "Show me what improvements/changes can be made in this PR"
```

This is where the fun really starts. The AI generates a list of detailed improvements that we might have overlooked
otherwise. Not just grammar and optics, but actual, substantial methodology and logic improvements. I'm smiling like a
proud parent here!

Here's a snippet of the response which you can
find [here](https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1#issuecomment-1838971826):

![questions-codium-pr-agent.png](/images/posts/questions-codium-pr-agent.png)

---

Next, we let Codium do what it does best using the `/describe` command.

```bash
python3 -m pr_agent.cli --pr_url=https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1 describe
```

This command blesses our PR with an introduction that pretty adeptly summarizes it. Applause, please!
[Here's the full description generated.](https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1#issue-2024089862)

![describe-codium-pr-agent.png](/images/posts/description-codium-pr-agent.png)

---

Now comes the royal rumble, my favourite. We put CodiumAI's PR-Agent to the ultimate test – the `/review`. This not only
gives you a summary of the PR; it also analyses the level of effort required to review it, checks for security concerns,
and provides constructive feedback and code-specific suggestions. At this point I might as well review my own code!
Here's a sample:

![review-codium-pr-agent.png](/images/posts/review-codium-pr-agent.png)

---

Finally, we utilize the `/add_docs` command. This results in potential documentation being popped in directly within
your code, making it so much easier for your fellow team members. With this, you've practically got an entire PR review,
neatly wrapped and delivered to your developer doorstep with a bow on top!

![Proposed docs](/images/posts/proposed-docs-codium-pr-agent.png)
![Proposed docs two](/images/posts/proposed-docs-two-codium-pr-agent.png)

## In Conclusion...

Isn’t it amazing when machines do the tedious work for you, and you can just pop in with your insightful, intelligent
comments to seal the deal? Nothing short of what developers have always wanted. Optimize for 4 years, so that you save
an additional 3 hours every day. Well, with Codium's pr-agent, you only need 1 hour.

I mean, why slog away doing the grunt work when CodiumAI's PR-Agent can handle:

- Automating the creation of PRs with commands
- Facilitating preparation of structured and detailed descriptions
- Easy-peasy analysis of PRs
- Detailed suggestions for code improvements

And it does all of that while catering to each developer’s unique needs and control freak tendencies! It’s like having a
highly efficient, attentive, machine-based colleague who never goes on leave even on Fridays!

So, all you master tinkerers, all you fellow Dev Dudes and Dudettes, if you fancy diving head-first into the ocean of
customizable options, CodiumAI's PR-Agent is ever ready to bring out your programmer alter-ego.

Facing off against GitHub Copilot, PR-Agent shines through with its open-source label, ready to roll up its sleeves and
take your developer life to the next level. Contesting against GitHub Copilot, backed by conglomerate giant Microsoft,
PR-Agent with the strength of versatility is a reminder that the right tool is not always the biggest name but the one
that fits snugly into our unique developer lives.

Well, that's it for today folks. Until next time, keep your curly braces matched and your coffee strong!

Over and out.

Brian Baliach

---

PS: I genuinely hope this cheeky jaunt through the wonders of CodiumAI's PR-Agent and GitHub Copilot has left you with a
smirk and a better understanding of AI-driven pull request management tools. Just remember, the right choice is not
always the crowd-favourite, but the one that is custom-tailored for your unique programmer needs!

Catch more insights and all things code at my blog: https://balysnotes.com. Or don't, and miss out on some top-tier
tech wit. Your call!

Tally-ho, Brian


Navigating the Pull Request Maze with CodiumAI's PR-Agent: A Comparison to GitHub's Copilot

There has been a lot of hype around this mysterious new complex technology of storing and exchanging money that is decentralized, distributed and public. **Well, Spoiler-alert: It's not as complex as most of us think.**

To be able to understand this technology, we'll be looking at Bitcoin as our case study, The most popularly used cryptocurrency that implements Blockchain technology under the hood.

This will be a 3 part series that will comprise of:

1. Blockchain Technology: A case study of Bitcoin
2. Implementing Blockchain Technology in Code
3. Understanding the Math Behind Bitcoin

Buckle up and let's get into it.

## So What is Blockchain Technology?
At its most simplified existance, blockchain basically defines a chain of blocks whose blocks store digital data and are interlinked with each other in a unique way. Let me explain further:

**1. Blocks** - They store Transactional data (i.e the way e-commerce sites store your transaction data like the date, amount and your name). So a single block can be defined as a group of transactions. These blocks also store unique information about themselves (known as a hash - a unique string of numbers and letters) that are used to identify the blocks in the blockchain.
**2. Blockchain** - These are a group of blocks that are interconnected with each other, pretty much like a database containing a list of blocks as its entries.

Now lets get deeper.

## How does Bitcoin implement Blockchain Technology?

For starters, as long as you ended up here, you know that bitcoin is the most popular cryptocurrency currently in use - Well, as of 17th October 2019 - Technology is very dynamic and so this might not be the case a few years later. Either way, most new cryptocurrencies out there are a fork of Bitcoin technology with a few tweaks here and there to try to overcome the limitations of Bitcoin. So at this point, I'd like to assume that it's safe for me to call Bitcoin the father of other cryptocurrencies.

So how does Bitcoin do it? Well, all this boils down to Cryptography (The act of securing communication between two points), Math, Technology and a [pseudonymous](https://www.google.com/search?q=pseudonymous+meaning&oq=pseudonymous+meaning&aqs=chrome.0.69i59j0l5.1175j0j4&sourceid=chrome&ie=UTF-8) Japanese person named Satoshi Nakamoto.

Let's consider bitcoin as a decentralized, distributed, public ledger. Decentralized in the form that no central bank controls controls it, Distributed such that every peer on the network contains a copy of the ledger and public also such that every peer on the network has access to this distributed ledger.

Now, let's also consider two popular individuals: Alice and Bob, who are trying to transact using bitcoin. So both these individuals start off which getting a Bitcoin Wallet - A program responsible for managing bitcoins which generates a private and public key pair where the private key is responsible for authorising transactions from your bitcoin wallet and a public key that is used as your public address when sending and receiving bitcoins. The public Key is generated from the private Key.

(You can read more about [What is a bitcoin wallet here](https://www.youtube.com/watch?v=A1Pl5hYHXiI) and [the differences between a bitcoin client and a wallet here] (https://bitcoin.stackexchange.com/questions/20487/whats-the-difference-between-a-bitcoin-client-and-wallet))

**So What is a private key?** A private key is a uniquely generated string of letters and numbers that will be used to authorise your bitcoin transactions (Basically, like a pin to your ATM Card).
**What is a public key?** A public key is also a uniquely generated string of letters and numbers - generated from the public key - that when hashed, will be used as your address when sending or receiving money. So this means for Alice to send Bob money, Alice will need to know Bob's public key.
**What is Hashing** - Well hashing is the process of converting a certain string of characters to a unique string of letters and numbers of a certain length through a hashing function. As an example, given a String `john` passed through a SHA256 hashing function, you get `96D9632F363564CC3032521409CF22A852F2032EEC099ED5967C0D000CEC607A` which has a total of 64 characters which is equivalent to 256 bits. If you are not a computer Guru - well, most of us aren't - I'll try to explain the math briefly. In computers, every single character in Hexadecimal notation has a total of 4 bits, ranging from 0-9 and A-F. Bits are basically zeros and ones which computers use to represent data. So in this case, the hash generated is a length of 64 characters and since every character is 4 bits, the total becomes 256 bits. This length of 256 bits produced will always be the same regardless of what you feed into the SHA256 hashing function. So even a String longer than `John`, say `Micheal` would still yield a 256 bit long String, except that it would be quite different from what was gotten when using `John`

So Alice and Bob have successfully acquired their Bitcoin wallets. Bob then decides to gamble with his rent money by betting on racing horses. Well long story short, the Horse Bob bet on wasn't actually a horse so Bob looses all his rent money. So Bob is on the verge of being kicked out of his home and at the same time is considering betting on a football match that comes on 4 hours later and therefore reaches out to Alice for financial help. Alice, having being brought up in a sharing family, decides to send Bob 2 bitcoins. So to do this, Alice needs Bob's Bitcoin address (which as we had discussed earlier, is Bob's hashed public key). So Bob sends Alice this address and Alice decides to send 2 Bitcoins to Bob.

To be able to do this, another important concept about Bitcoin should be understood, and this is that bitcoin does not store people's balances. Bitcoin rather stores a list of all transactions that have taken place since it's birth. Therefore, to prevent Alice from sending money that she doesn't have, the Bitcoin  client will look at previous transactions that Alice was involved in (Referred to as inputs in bitcoin terminology) and check whether Alice received a sum-total that is either equal to or greater than the amount Alice wants to send, in this case 2 Bitcoins and also whether these transactions were already involved in any other transaction. If the inputs pass these parameters, then it is verified that Alice has at least 2 bitcoins in her account and can be able to send them. Also, it is important to note that not always will the inputs be exactly equivalent to the amount Alice wishes to send and therefore the surplus amount will be sent back to the Sender. So if Alice's previous transactions add up to a total of 3 bitcoins, then the extra bitcoin will be sent back to Alice.

Alice is the heir to a massive estate and therefore very wealthy, and Alice recalls that she had recently converted a couple millions to bitcoins and had this money sent to her address by the bank she was using. So Alice is quite confident that she has the capability of sending Bob 2 Bitcoins, so Alice authorises the transaction.

To be able to authorise and validate transactions, we need to understand that for starters, the bitcoin network is an interconnection of multiple nodes all containing the public list of transactions. These transactions are grouped together in blocks and this blocks are inter-linked together to form a block-chain. Each block has a unique hash that identifies it (generated from the transactions in that block together with the hash value of the previous block) and every next block in the block-chain stores this hash value of the previous block. This way, Blocks cannot be swapped with other blocks within the block chain since new blocks will always have a different hash value. At the same time, since the block's hash value is generated from the list of transactions, changing a single transaction in a block will change the hash value of that block and subsequently all the other hashes of following blocks. This is therefore an important security feature of blockchain technology that we'll look at later.

So Alice inputs Bob's bitcoin address and presses the send button on her wallet. This generates a transaction that is added to a list of unverified transactions on the bitcoin network - So this transaction hasn't been added to any block, and therefore not on the block-chain, and therefore not on the public list of transactions. For this transaction to be considered valid, the nodes on the network will first check whether the inputs (As mentioned earlier, previous transactions) have been used in any other prior transactions. At the same time, these nodes check on whether the send to address is valid. So in general, the Bitcoin network performs the following tasks before considering a transaction/group of transactions are valid:

### Steps run in the Bitcoin network:
**1) New transactions are broadcast to all nodes** - Alice's transaction is broadcast together with other transactions currently taking place, to all other nodes in the network. Nodes here are Bitcoin clients running connected to the network. Bitcoin clients are programs that you install on your machine that perform these tasks.
**2) Each node collects new transactions into a block**
**3) Each node works on finding a difficult proof-of-work for its block** - Here, proof of work defines a mathematical problem that a node needs to solve in order to mark a block of transactions as valid. I'll talk more about this in the next section
**4) When a node finds a proof-of-work, it broadcasts the block to all nodes**
**5) Nodes accept the block only if all transactions in it are valid and not already spent**
**6) Nodes express their acceptance of the block by working on creating the next block in the
chain, using the hash of the accepted block as the previous hash**

### So what is this proof-of-work jargon?

Well, the answer to this question my also be the answer to other questions you might have: like where does bitcoin come from - can also rather be phrased as where did the first bitcoin come from - or does Alice have a thing for Bob, or whether Bob has a gambling problem and should sick professional help. Either way, hold on to the railings cause this Titanic is about to hit an iceberg.

So as we mentioned earlier, every pending transactions is held in a virtual pool that can be identified as a pool of unidentified transactions. The nodes in the bitcoin network are responsible for verifying these transactions and putting them inside a block. These nodes also attempt to solve a mathematical problem through which they use the correct answer to this problem to mark a block as valid. In the end, the node that does this first, gets rewarded for the work in form of bitcoins. As we also mentioned earlier, bitcoin uses a hashing algorithm to generate addresses. Bitcoin then uses this same technique to generate a mathematical problem, say generate a certain hash value whose first 32 bits are zero. Since such problems can only be solved through brute-force (continuously guessing using random values until you achieve the desired result) this makes the probability of solving such guesses at 2^32 since a single bit can only have two states, 0 and 1, and this value equates to above 4 Billion guesses! So there is a single solution every 4 billion guesses. A node on the bitcoin network approximately solves a mathematical problem every 10 minutes so bitcoin fine-tunes the mathematical problem such that this aspect is maintained. So this entire phenomena of solving a mathematical problem so as to validate a single block is what is referred to as **Bitcoin Mining**.

After all parameters of Alice's transaction check out, the transactions is considered valid and added to a block that has been validated and Bob is free to either pay his rent, or make another betting blunder. At the same time, a certain bitcoin amount is sent to the minor - pretty much like a transaction cost - As a thank you to the miner for devoting their computer's precious time and power to solving blocks. Because the transaction has been sent to Bob's public address, only Bob has his private key and therefore he's the only individual who can spend the bitcoins associated with his public address. Therefore, whoever has the private key - Stored locally by the bitcoin wallet up as a wallet.dat file - controls the bitcoin, So you should consider keeping your private key as private as possible.

**This is how bitcoin greases it's continually moving gears in the bitcoin network. Wasn't so hard after all was it?**

If you're a sceptical type of individual, you may have questions about whether or not this network controlled by everyone is secure on not, so in this next section, we're going to look at Security issues in bitcoin and how Bitcoin overcomes them.

### Security issues - Also contains a somewhat more technical explanation of 'proof-of-work'
### 1. Transaction Order:
Every new Bitcoin transactions is broadcast-ed across the network to all other nodes. In this case, Bitcoin is decentralised such that every Bitcoin client contains a copy of all the transactions made in Bitcoins. Therefore, you cannot always accurately state that a transaction reaches all nodes in the bitcoin network at the same time. Consider an example: Alice wants to buy a car from Bob. Alice makes the transaction and sends Bob 5 Bitcoins for the car and waits for Bob to ship the car. Afterwards, Alice then uses the same inputs she used to send Bob 5 bitcoins and send herself back the money. Due to different network propagation times, some nodes will receive Alice's second transaction of sending herself back the 5 bitcoins before they receive Alice's transaction of sending Bob 5 bitcoins. These nodes would then consider the second transaction they received as invalid since they would be re-using inputs.

#### How does bitcoin overcome this?
Bitcoin arranges all transactions in a block (a limit of around 2400 transactions per block). These blocks are connected together in a chain, where every block references the previous block. You can therefore traverse these blocks in order, to the first transaction ever made in bitcoin. This therefore solves the problem of order, **but in what way are these transactions added to each block and in the correct order?** In this case, nodes take the **'un-ordered'** or **'unconfirmed'** transactions and puts them in a new block and broadcasts this block to the rest of the network. The un-ordered or unconfirmed transactions are transactions recently completed but have not been included into any block yet. But this also creates a problem in that multiple nodes could create their own Blocks containing the same transactions and broadcast them to the rest of the network. **So how does the network know which block to choose?** Bitcoin dictates that each valid block must contain an answer to a specific mathematical problem. Bitcoin therefore uses cryptographic hash functions, which are basically functions that when given a message as input, gives a random string of letters and numbers of a specific length (called the **message digest**) that is unique to this input as the output. This output will always be the same given that the input does not change. Changing even a minor part of the input will cause the output to change completely. These functions are referred to as **one-way functions** since you cannot use the output to inversely try to retrieve the input. In this case therefore, the only way of discovering the input is to run multiple guesses at a time until an output that matches the given output is produced. Bitcoin uses an algorithm: SHA256 that generates an output of the length of 256 bits. The mathematical problem that the nodes now have to solve is generate a certain hash value whose first n bits are all zeros (n can be any numerical value). To put this more into perspective, the total number of guesses that can be made is 2^n guesses, depending on the value of n. if n was 32, the total number of guesses would be 2^32 which is above 4 billion guesses, as we had calculated earlier. Therefore, bitcoin network fine-tunes the value of n such that the correct input will be produced around every 10 minutes. As we stated earlier, This phenomena is referred to as **Bitcoin mining**

The mathematical probability of this problem makes it very rare for more than one node to arrive at the correct input at the same time (i.e if n was 32, the probability would be one in over 4 billion guesses) but in cases nodes do overcome this probability and solve the problem at the same time, both blocks generated by these nodes will be considered valid and will be added to the block chain and the block's hash be used in the next block. This therefore raises another problem where there will be duplicate blocks in the chain so what the network does, is accept the longest block-chain as the proof-of-work. It is highly improbable that other nodes will again end up at a solution at the same time for the next block (due to how the mathematical problem is constantly fine-tuned) and therefore, there will always be a longer block chain and this chain will be considered as the valid chain by other nodes and therefore duplicate chains will be discarded. The reasoning behind this is that as long as honest nodes occupy the majority of the bitcoin network, the longest chain will be attributed to majority nodes working towards solving the mathematical problem (guessing correct values of the n number of zeros) therefore winning against all other competing chains in the network. Therefore, the longest chain will certainly always be produced by the majority number of nodes since the more the nodes trying to solve the problem, the higher the probability that the problem will be solved faster and therefore the block chain will grow faster. i.e., in the case of 4 billion guesses, a group of 1 million nodes will achieve the solution faster than a group of 1 thousand nodes, which makes it even harder for a single attacker with one node to win the race against the entire network.

It is therefore advisable to wait for more blocks to be added to the block chain before being sure that a transaction is actually valid since it becomes significantly harder to generate a longer block chain the further back you go in the chain. Consider this, our chain has 4 blocks already and the majority nodes are adding an extra valid block every 2 minutes, so for an attacker to be able to control this network, they need to have enough computing power to generate newer blocks faster than the network itself. So if the block chain grows to 8 blocks and the attacker has their copy of 4 blocks, they have to create the subsequent missing 4 blocks before they get to 8 blocks. Since the other nodes in the network are still actively creating blocks, this makes it very tough for the attacker to catch-up to the speed of the network the further back in the block-chain the attacker is.


Whoa! That's a whole lotta information to take in but I'd like to assume that deep down, you feel that it was worth it.
Thanks for reading and if you have any questions or clarifications, don't be afraid to leave a comment behind:-)
Also, stay tuned for the next post in this series: **Implementing Blockchain Technology in Code**.
You can also choose to read more on Bitcoin on the original paper posted [here](https://bitcoin.org/bitcoin.pdf)

#### au revoir:-)


Blockchain Technology: A case study of Bitcoin

Showing posts from ai tag

Introduction to Domain Driven Design: Bridging the Gap Between Complex Systems and Software

Navigating the Pull Request Maze with CodiumAI's PR-Agent: A Comparison to GitHub's Copilot

Blockchain Technology: A case study of Bitcoin