DEV Community: Laurent Senta

Using MerkleTree for Blockchainized Document Certification

Laurent Senta — Wed, 15 Sep 2021 09:42:08 +0000

As a freelance I worked on document certification using blockchain. I received several similar requests, but one of them required the implementation of a new data structure: Merkle Trees. It is a data structure widely used in decentralization and for good reasons, thanks to Merkle Trees and Merkle Proofs we set up a certification system with unique properties.

Use cases

In a previous article I described a blockchain timestamping system that allowed one of my clients to certify contracts in an irrefutable and relatively affordable way. One important feature was the ability to prove that a contract was NOT generated a posteriori.

I received a similar request a short time later, with additional constraints. Imagine a service that allows a company to certify the role and salary of its employees. Once this certification is issued, employees may prove, through my client's tool, the veracity of their résumé to a potential employer. It is a type of verification that comes with new constraints:

Constraint 1, Scalability

The quantity of document to be certified was much greater (hundreds of thousands per batch). This makes the "obvious" timestamp system prohibitive: it costs a few pennies to stamp a document. Multiplied by hundreds of thousands of documents, we reach tens of thousands of dollars per batch.

Constraint 2, Confidentiality and Right to Be Forgotten

The document and its proof must remain in the hands of the user. Once the certification has been produced, we want to give the user full control of their data. We must therefore be very attentive to the information that is shared. You cannot timestamp a batch of documents as a single file, because you would then have to send ALL documents to all users.

Constraint 3, Durability

Certification must persist for decades, even if the service provider disappears or abandons the product. This makes decentralized storage systems like IPFS hard to defend because they require "someone" to persist the data. Note that today a service like Filecoin might be suitable, but the solution we have put in place is always more cost effective.

Data Structure: The Merkle Trees

In the previous article we saw the hash functions that let you to calculate the fingerprint of a document. These functions are very useful, because if two people have a document they can quickly calculate their fingerprint and compare them without having to exchange the whole file.

In our case we will push the use of hashes even further with a data structure called the Merkle Tree. It is a tree for which each node contains the hash of its children.

The construction of the tree is simple, we calculate the fingerprint of each document, then we group these fingerprints two by two, and we calculate a new hash. The operation is repeated until a single fingerprint is obtained. This last hash is called the root of the tree.

It is a recursive operation that allows us to take any number of documents and produce a single fingerprint. This is very efficient for our service because we can time stamp this last imprint by following the method in the previous article.

Using this approach, we can timestamp hundreds of thousands of documents very quickly. It takes a long time to compute the tree, but it's an off-chain operation run on a "regular" server. It doesn't cost much. We end up storing a single fingerprint on the blockchain. The cost on the blockchain is therefore the same, regardless of the number of documents to be certified.

This property allows us to pass Constraint 1 (Scalability)

We timestamp the root of our hash tree on the blockchain, and we send a proof to our users.

Merkle Proof

The Merkle Tree has another interesting property: it is possible to prove the existence of any document in the tree without knowing the other documents.

If I send you a document and the intermediate hashes, you can recalculate the root fingerprint and therefore verify that my document has not been modified. For example, in the diagram below, with the two intermediate hashes (in blue) and the Contract B, it is possible to find the root.

Note that for 4 documents, the proof contains 2 intermediate hashes, For 1024 documents, the proof contains 10 hashes, For 500,000 documents, the proof contains 19 hashes. There is a logarithmic relationship between the input data and the size of the proof sent to users. Basically, the more documents you have, the more "profitable" the solution becomes.

In practice

In practice, this means that a end user has to hold the document AND the proof (the intermediate hashes).

This is an additional constraint but this compromise is useful in our case: only the end user receives the proof associated with their document, therefore they are the sole master of their data.

This property allows us to pass Constraint 2 (Right to Be Forgotten)

Demonstration

We adopted the QR Code solution, here is an example:

This QR Code contains Andrew O’Reilly’s identity, his role in the company, AND proof of merkle. If you read this QR code with your phone, you should come to a web application that will perform the verification described above.

You can also test the application by opening this page

Here is a screenshot of the verification result:

In the next QR Code, I changed Andrew's role to pass him off as the CEO of the company:

It will open the following link: Demo Page you will see that the evidence fails.

And here is the capture of the failed verification:

Note that these QR codes are quite large because they contain ALL of the data to be verified. Our certification system is therefore not based on an external service to store the data, which makes the service sustainable.

This property allows us to pass Constraint 3 (Durability)

The Off-chain Part

The off-chain part is similar to that mentioned in a previous article.

The Blockchain's complexity is "absorbed" by the off-chain part and hidden from the rest of the application. Under these conditions, the blockchain becomes a service "like any other" which provides a very specific functionality in our infrastructure.

Some important details

If you need to implement a similar service, consider:

Make sure that the hash creation and verification process is deterministic:

When checking the proof, we only have the hash to check and the hash of the current proof. However, Hash (A + B) is different from Hash (B + A), so we have to define an ordering for the hashes. For the sake of simplicity I sort them alpha-numerically. Thus the process of calculating the proof is based solely on the information that we have during the proof.

Add entropy on "simple" data

In the case of identity verification, one must take into account the possibility that a malicious user tries to brute-force the fingerprints. With some initial information (name, first name, role), it would be possible to "guess" the other missing information. To avoid this, I add a random string of characters in the data. This makes the hash of the proof unpredictable, even with some or all of the initial data.

Ultimately

The merkle tree is a structure widely used in decentralization. It has very useful properties, in our case it is used to timestamp hundreds of thousands of documents at minimum cost. The proof system lets us implement a timestamping system that also preserves the confidentiality and durability of user's data.

A demonstration of the application is available: blockchain-proof.singulargarden.com.

You can use the QR Code feature as shown above. There is also a more classic document verification on the home page. Here are two sample files and the proof.

If you want to know more or have any questions, please reach out on LinkedIn or Twitter.

You can find the latest version of the article, and subscribe to more on my site.

Ethereum Use Case: Document Certification

Laurent Senta — Mon, 13 Sep 2021 11:52:08 +0000

As a freelance, I worked on documents certification using the Blockchain. This is an interesting problem because it is a type of feature that we could not implement in a trustless way before. Thanks to this type of project, companies that have not yet "jumped" into decentralization are getting their first taste of the ecosystem and can implement completely new features.

Public blockchains are great for timestamping.

A public blockchain like Ethereum or Bitcoin is a database that the whole world verify at all time. No one can get around the rules of the Blockchain, not even its creators. As a result, the data stored there is exceptionally reliable.

A use case of the Blockchain is therefore timestamping. The idea is to allow an entity, for example, a company, to certify a document by publishing the information "we, Acme Inc., certify the veracity of this document as of date X."

It is very different from a centralized system: in a centralized system, an administrator, or a hacker with administrator rights, may modify the data or the program at any time. It would be possible to timestamp data a posteriori for example.

Use-case: Irrefutably prove the signing of a contract on a specific date.

A team contacted me to set up a document certification tool. They needed to generate and sign contracts with their users and have proof of each contract's existence on the date of signing. These contracts have many legal implications, and they are very binding for them and their clients: the proof must be irrefutable.

The Blockchain was an ideal solution in this case. It allows proving that the contract was signed on a verified date and with a verified content. There is no need for a third party, so the evidence is as reliable as the crypto tools used by Ethereum.

Basics of Crypto: Digital Fingerprint

In areas related to Blockchain and networks, we are very attentive to data. Storing a few bytes of data on the Blockchain involves duplicating them millions of times on all the machines on the network. This is an expensive operation: we must transmit the data, verify it, and store it indefinitely. Therefore, we have to be smart when we ship and verify data.

This is where hash functions come in. These functions allow you to calculate a file's fingerprint. This fingerprint is unique. No other file has the same fingerprint. So, just as a fingerprint identifies a human being, a file's cryptographic fingerprint uniquely identifies a file.

Here is the hash of the first chapter of The Little Prince by Antoine de Saint-Exupéry: d4b4e3e2b91edaed75b7791ced10afd53441e7f19e463a8b675619a081e3152d
By changing the first letter, the hash is completely different: 009d8d2e8fd8e5a049c148bece24f1fdf401b87d5a0483ef910e367f273c891d

(I am using the SHA256 algorithm)

If I want to prove to someone that I own a file, I can share the hash of that file with them.

These are ideal for our use-case: We calculate the hash of every contract, and we publish it. We don't need to publish the entire file, which preserves confidentiality and drastically reduces our costs.

Smart Contract

For this client, we set up a "Smart Contract" on the Ethereum Blockchain. It's a piece of software that "exists" in Ethereum. It doesn't reside on a computer on the client's network; this program resides "in" Ethereum. As a result, it benefits from all the network's properties: impossible to falsify and cannot be modified without abiding by the rules of the network.

We interact with this program by sending Ethereum transactions that contain data and instructions. That is very similar to an API but on the Blockchain.

In this case, the timestamp contract we are using is straightforward: it has an owner and a "timestamp" function which outputs a timestamp signal.

This is what our Smart Contract looks like:

A few notes:

We use OpenZeppelin, a common framework in the industry. It provides a reliable implementation for many classic features. Here we use Ownable: the contract has an owner, and he is the only one who can call the timestamp function thanks to the isOwner transformer.

The timestamp function is highly optimized. We do not store data in the SmartContract's memory because it is an expensive operation. Instead, we emit a log to keep a trace of the timestamping process. Because of that, we won't be able to modify the data later, but this is a good trade-off for our use case.

The timestamping process

The process is:

We compute the document's hash,
Using our "administrator" account, we send a transaction that asks the SmartContract to process the hash. This hash is recorded on the Ethereum blockchain "definitively".
We can now send the document a link to the transaction to the end-user. They will be able to prove irrefutably that the contract was certified at a given date.

You can find the example of such a transaction on the Blockchain Here. According to today's price (September 2021), this operation would cost 15 cents.

The Off-chain Part

We have seen the relatively simple Blockchain part. However, in practice, for such a project, we must take care of other issues such as the security of the admin keys, error management, scalability, etc.

In our case, we needed to sign a large number of contracts quickly. Unfortunately, transactions on Ethereum are relatively slow. You may have to wait several minutes for a confirmation. So we set up a service that lets the rest of the application interact with the Blockchain asynchronously.

Off-Chain Infrastructure

The Blockchain's complexity is "absorbed" by the off-chain part and hidden from the rest of the application. Using this approach, the Blockchain becomes a service "like any other," which provides a particular feature to our infrastructure.

This is just the beginning.

This system processes nearly ten thousand contracts daily. But of course, it's a sketch of the final product. We still lack details about keys management, parallel transaction management, errors, etc. I will be posting more articles on the subject, so you may want to subscribe on laurentsenta.com.

If you want to know more or have any questions, please reach out on LinkedIn or Twitter.

Where and how application data is stored in Ethereum?

Laurent Senta — Wed, 12 May 2021 10:24:23 +0000

This article was published in 2017, updated in February 2021.

Ethereum is used to build decentralized applications, a.k.a. DAPPs. These applications exist through small programs that live on the Blockchain, called smart contracts.

Before jumping into the platform and writing a smart contract, it’s really important to understand where your application data is stored. Code execution, servers and programming language are rarely critical to the design of an application. But data --its structure and its security-- will constrain our design the most.

Let's imagine we are porting apps to Ethereum:

For a Facebook-like, where are the publications and comments data?
For a Dropbox-like, where are my private files?
For a Slack-like chat app, where do we store discussion channels? And what about private messages?

The Account Machine

Let’s skip the explanation of blockchain for a minute (you can read my post on why Blockchain can be best understood as a machine that generates Consensus here). Let’s look at Ethereum from a higher level of abstraction -- the software that powers it, which is basically a big, slow, reliable computer.

Ethereum holds a set of accounts. Every account has an owner and a balance (a quantity of Ether).

If I prove my identity, I can transfer Ether from my account to another. The money will flow from one account to the other. It's an atomic operation called a “transaction”.

In other words, the Ethereum Software is a transaction processing system that works as follows:

The system is in a certain state, i.e. every account has a certain balance.
We carry out one or more transactions
We get a new state: an updated set of accounts and their balances.

It’s as simple as that!

With that out of the way, we can turn our attention to how to execute code and programs within a transaction. And that's where Smart Contracts come into play.

Robot Accounts

Every account has an owner and a balance. But some of these accounts are special: they own themselves. At creation time, we give them a piece of code and memory. That's a Smart Contract.

A smart contract is really a smart bank account. The term "contract" is unclear—I prefer to think of them as Robot Accounts.

A smart contract is basically a robot that executes some code when it receives transactions. This transaction happens within the blockchain. It is public, replicated and validated by the network. That means a smart contract won't fail because of a power outage in a Datacenter.

A smart contract has a balance, some code, and some storage. This storage is persistent, and that’s where we’ll find DAPP data.

Storage of Robot Accounts

When a smart contract is created or when a transaction awakens it, the contract’s code can read and write to its storage space.
Here’s a breakdown of its Storage Specifications:

It's a big dictionary (key-value store) that maps keys to values.
Keys are strings of 32 bytes. We can have 2^{32 x 8 bits} = 2²⁵⁶ different keys. Same for values.
It's like Redis, RocksDB or LevelDB storage.
DAPP and Smart Contracts function in a similar way to a hard-drive storage in a regular program.

Here's an example of a Smart Contract structure. It uses the Solidity Programming Language:

'' Solidity Code (solidity.readthedocs.io)
struct Voter {
 uint weight;
 bool voted;
 uint8 vote;
 address delegate;
}

2²⁵⁶ keys x 32 bytes (values) is around 10⁶³ PETABYTES. You would need several billions of times the age of the universe to go through this amount of data with an SSD.

Basically, we can safely assume that there’s no storage limit for a DAPP.

But there is a cost:

DAPPs Fuel

For every transaction, we add some Ether, the fuel needed to power it. The emitter of the transaction pays this tax to motivate the miners to process the transaction. Miners ensure the network is reliable and we reward them with some Ether.
So we send transactions and some fuel to this big machine. When the transaction targets a Smart Contract, the Ethereum machine starts the Account’s Robot. Each action of this robot will burn some more gas.
The actions taken by this robot are translated into instructions in the Ethereum Virtual Machine (EVM). There are instructions to read in storage, instructions to write, and so on. Each of these transactions has a cost in fuel, and that cost will constrain how much storage we can use.

Storage Cost

The cost of each instruction in a Smart Contract will limit the amount of storage it uses. In theory, Ethereum enables infinite storage space. But, in return, you have to provide gas for every read/write operation.
This cost changes all the time, depending on the network, the market and the way Ethereum specs develop. To get a general idea of the pricing, I simulated a few Smart Contracts:

I tried three operations:

Writing a uint8 (one byte) in storage
Incrementing a uint8 in the storage (read then write)
A simple voting function, which checks whether the emitter of the transaction has the right to vote and then updates the vote result. You can vote only once; the second attempt is short-circuited.

Code and tools are in the Appendix below. Here are the numbers:

(note from 2021: numbers here are outdated, but the currency is so volatile these days, use this as a rough order of magnitude).

Based on this table, this article would cost around 50 Euros to store with a Smart Contract, excluding pictures.

Posting a tweet costs a few euros, and ordering on Amazon a few cents.

Of course, these are estimations with different orders of magnitude. The exact cost will depend on the exact instructions you use, as well as on the network load, the current price of gas, etc. New algorithms might also bring down the price of Ethereum (Proof Of Stake).

Finally, where should I store my data?

Well, maybe not on the Ethereum Blockchain. The data stored there, with Smart Contracts, is safe and easy to access. But the cost and the structure of the store is especially suited for metadata-related uses.
Taking the examples from the introduction: User Posts, Files and Message Boxes will probably be on another platform like IPFS. In the Ethereum Blockchain, we would store critical data, like encryption keys, roots to storage trees & authorizations.

Find all my previous articles on laurentsenta.com

Appendix

Piece of code used for the table:

pragma solidity ^0.4.0;

contract Test {
    mapping(uint =\> uint) tests;

    function Test() {
    }

    function one_set() {
        tests[0] = 0;
    }

    function two_increment() {
        tests[0] = tests[0] + 1;
    }
}

/// Give a single vote to proposal $(proposal).
function vote(uint8 proposal) {
    Voter storage sender = voters[msg.sender];
    if (sender.voted || proposal >= proposals.length) return;
        sender.voted = true;
        sender.vote = proposal;
        proposals[proposal].voteCount += sender.weight;
    }
}

Tools used to run the code and evaluate the costs:
Ethereum Gas Station to follow gas cost
Remix Solidity IDE to write and run Smart Contracts

Ethereum Gas Station to follow gas cost
Remix Solidity IDE to write and run Smart Contracts

How to stop falling for the Shiny New Toy Syndrome

Laurent Senta — Fri, 22 Jan 2021 14:09:30 +0000

For those creators that are spending too much of their time catching up: that’s ok. Here is a fix.

Summary: This article is for creators feeling the Shiny New Toy Syndrome. I believe this is expected, and I describe why. Then we go on with a few methods that might get us out of it.

Are you spending a lot of time reading about new technologies? How often do you wonder if you should try this new tool, this new language, this new framework? How often do you use a technology that you just started using?

The JavaScript Fatigue, Decision Fatigue, or any other fatigue is lurking

You spend a lot of time thinking about which tools are the most efficient to do your job, and you spend a lot of time trying new things.

Here is a secret you might know already: you spend a lot of time learning things that you don’t need, and you don’t build as much as you should.

That’s you? Then nice to meet you! 👋 We’re both addict to the shiny new tool syndrome.

That’s perfectly natural

Creators are eager to create new things. That’s obvious.

And as a creator, we are very sensitive to new things around us. Maybe they make you uncomfortable “someone is having success with another great idea I wanted to build.” Or perhaps they intrigue you “that looks so much better than what we had before; I need to try this.”

We’re always on the lookout for things changing around us. That’s perfectly reasonable and even expected, below a certain point.

I believe it becomes a problem when we spend more time learning about new things than using them. Or when we spend most of our time working with tools, we don’t really know.

For years, I’ve read bazillions articles about new technologies

Always on the lookout for the latest HackerNews articles, following hundreds of RSS feeds. That felt amazing, every time a discussion about a new tech arise, I knew about it, and I already had an opinion. I tried so many of them.

I forgot most of these techs, and most of these are dead. Have you ever heard of famo.us? The future of web apps, with their 3D rendering engine that was shaking the world? They build Shopify stores now, and Facebook is still in 2D.

I’ve fallen for this trap multiple times. I’ve seen teams and clients fall for this trap too, and I’ve found a few ways to mitigate this.

It's about learning!

I believe this is why we do this: we love learning new things. Every time we learn, we get a small release of dopamine. Success your brain tells you, I like when that clicks, do it again.

But the more we know a tool, the less learning we get per unit of time using it. The less dopamine we get from actually using that thing.

When I try a new Software, give me 25 minutes with it, I learn 5 things about it. But after years, I might discover one novel idea every month.

The more we know a tech, the less rewarding it is to use it. Especially if you care too much about learning. I recognize this as the “Sugar” of my Knowledge Worker role. Learning rocks, especially at the beginning of a career, but it isn’t sustainable by itself. That applies to businesses and individuals alike.

So learning is my thing, is it yours?

I wouldn’t be surprised that’s the same thing for you.

The way we share information and organize ourselves promotes the Shiny New Tools Syndrome

Say I release a new JavaScript framework tomorrow. I’m going to talk about it and make sure the information spreads. I’ll get a bunch of curious people to learn about it.

What’s the rational thing to do once you spent time learning? You write about it. And that is the first rule of content marketing: If you publish about something, you become an expert. And if you’re an expert, you get more views, and you get more money and more jobs.

It’s easier to become the top 1% expert for software with twenty users than it is to become the leading expert for some old school beast that has seen generations of users.

So following trends is incentivized, and it’s rewarding.

Up to a certain point.

How to come back from the shiny toy syndrome?

A few ideas, I’m still learning on this,

Define who you are

Define what your competitive advantage is and where you should be on top. Then forget about everything else.

Here are a few decisions I took recently:

I am not a Javascript Runtime Expert, and I’m not building infrastructures that rely on these runtimes. I use these infrastructures. So I haven’t looked for a minute at Deno. I might use it in a few years.

I am not a Frontend Expert, and I am not a Frontend Architect. I know enough about data management and how to separate concerns to ignore state management libraries in the frontend. I’ll use whichever is by default in my library.

My clients don’t hire me for my UI designer skills, and I don’t care about scaling UI to large teams. I know enough CSS and HTML to use a “ready to use” toolkit. I won’t use TailWindCSS or anything more recent than SASS and Bulma.

Choose mature tools and forget about them

First, keep in mind that tech hardly becomes obsolete. Once it reached mainstream status, a piece of tech will stay around for a LONG time.

If you’ve heard about a 50 years old book, you can bet this is a good book, and it’ll be around for 50 more years. A trendy book released last year might not stand the test of time.

Are you going to use this a hundred times?

Because we hear a lot of success stories about new gadgets, we think we should use them. I think that’s ill-advised. We should ask if the gadget we are going to use is going to pay itself.

When you learn a new tool or a new skill, ask yourself: am I going to be more productive on the first project? Nope, On the third project? Maybe, On the fifth project? You might have wandered to another tool anyway.

"Knowledge is only a rumor until it is in the muscle."
~ Various and contradictory sources

And you know what happens to a rumor after a few weeks? You forget about it.

Because the high of learning is so quick and rewarding, we have to use the rest of our brain to think about the long term. Stay away from things you won’t use a hundred times. Don’t even think about it. They’ll come back later, and you can catch up because you’ll have matured on fundamental skills.

Keep it fun

This one is the hard part. How can we keep working with our mature and old tools rewarding?

I have a few strategies:

first of all, I work using the Pomodoro Method. Completing a Pomodoro is a reward in itself. Using old tools means I can complete tasks faster and this is rewarding.

Second, I redefined the metrics I focus on, like releasing new code, having more users, etc. This is where makers have an edge against creators working within a company. They can define and align their incentives however they want.

Third, I stay on top of a couple of very tiny circles of interest. This is where I get all my “Software Engineer High”.

Next Steps

Now, can you write down the tools you are going to use for your next hundred projects? Or at least your next five projects?

If this content resonates with you and you want more of it, please like and let me know! That's the only way I can tell if I should keep going.

Also, I’m working on a new article called The One Year Stack, so I’d love to know more about your process. Leave a comment and let me know how you deal with that SNT Syndrome :)

orbital-list 🪐 - My first React Library

Laurent Senta — Fri, 08 Jan 2021 10:49:10 +0000

A while ago I wrote a web application that lets you see your team and coworkers on a circular clock.

This circular interface is the core feature of whena.re to me. Time, especially the time of day, goes round and round. It's more natural and more intuitive to represent it on a circle.

This design took me hours and hours to implement. I skipped the data visualization libraries because most of them rely on an abstraction that is data-oriented. It wasn't ideal here.

For example, if I have a list of users, in React you'd go with something like this:

<ul>
  <li>Tom (GMT, 12:02)</li>
  <li>Martine (UTC-2, 14:02)</li>
</ul>

// which you write:

<ul>
  {users.map(user => <li>{user.name} ({user.timezone} - {user.time}</li>)}
</ul>

Whereas in libraries such as d3, you have to convert your data into "pie chart data" and setup some sort of rendering engine. Like in this example.

In the end, I wrote a library of components that would let me represent circular interfaces. It generates a "circular context" and position components inside this context.

It looks like having HTML lists displayed as orbits.

<OrbitalList>
    <Dial color='#1f2041' />
    <Orbit color='rgba(244, 205, 205, 1)' radius={0.15} />
    <Slice
        length={0.5}
        angleStart={180}
        angleEnd={202.5}
        color='blue'
    />
    <Place
        angle={180}
        distance={0.8}
        style={{ color: '#ed254e', fontSize: '1.2rem', fontWeight: 'bold' }}
    >
        <button>Hello</button>
    </Place>
</OrbitalList>

Today I release this as an open-source library. It's small, the code is embarrassing, but you know what they say...

"If you're not embarrassed, you've launched too late."

I'd be happy to hear from you, if the approach makes sense and if you find the demo and library pleasant to use.

The demo is here:
https://orbital-list.laurentsenta.com/

The GitHub repository is here:
https://github.com/laurentsenta/orbital-list

The Pomodoro Method hacks how you define your tasks

Laurent Senta — Tue, 08 Dec 2020 16:55:41 +0000

Do you know the Pomodoro Method? Here's a quick slice of the benefits hidden behind its rituals.

It's hard to define tasks in the right way.

You'll find this advice everywhere:

Only define goals and tasks you have control over.

Tasks that you don't have control over are productivity killers.

For example: "get a positive answer to proposal X," "get thousands of followers," "finish project in time."

These goals mess with your definition of done.

The world is moving around you, and it's hard to achieve something and get a feeling of progress if it depends more on the rest of the world than on your actions.

That's why I like the Pomodoro Method: When you start using it, it'll force you to add a subtle layer of Pomodoro on top of each task.

The Pomodoro Method redefines how you measure success

Your task list for today might resemble something like that:

How many of these depend on something external?

What happens when the requirements for Project A change and you have to start over? Do you need to wait for another document before replying to Arthur? Or what if the complexity of the issue you were working on explodes and you need to make three more decisions before finishing your job?

On some days, I might end up with zero tasks completed. Even after seven, eight, or ten hours in front of a computer. This is exhausting.

At the end of the day, I might have completed ZERO tasks. But when I apply the Pomodoro Method, I still have feedback of the time I spent pushing things forward anyway:

That would be a fantastic day. These Xs mean that I completed fourteen sessions of 30 minutes of deep focus. That's 7 hours of work. And these two C mean that I slid out of focus only twice during the day.

I can tell how much progress I made with the Pomodoro Method, even if I couldn't complete any task.

That's where the Pomodoro Method is ingenious. It adds a subtle layer where "a deep focus session" is a success in itself.

The one thing you have control over, your focus, becomes the real subject of most tasks. And with the Pomodoro "layer", you have a metric of success that tells you if you've been focused and lets you ask, "should I change something in my workflow?."

This method is crucial to me; I'm trying to have more people use it "the right way." That's why I published an interactive step-by-step guide on my website. I'd love to know if this helped you in the comments.