DEV Community: Dayana Mick

A Medium-Rare Brain Understanding the Essential Tools of Modern Cryptography Part 1

Dayana Mick — Tue, 07 Oct 2025 17:08:21 +0000

I started watching the second session of the Bootcamp with 0xMilica, and as she predicted, my mind got partially fried — not completely, but medium-rare — so I had to portion the recording into two parts to be able to follow along.

Let me attempt to take you on this journey of 0s and 1s, algorithms, problems, eavesdroppers, and brains frying and melting concurrently.

1. Bitwise Operations

We saw the truth tables for AND, OR, and XOR (which, for me, sounded like a wizard's name 🧙‍♂️).

A truth table is a simple chart that shows how a logical operation behaves for every possible input — listing all possible combinations.

Let me share them with you:

Truth Table for AND

True only if both bits are 1.

Truth Table for OR

True if at least one bit is 1.

Truth Table for XOR

True if the bits are different. It is reversible and used in simple encryption.

XOR is self-reversible: if you XOR a message with a key to encrypt it, and then XOR the result with the same key again, you get the original message back.

I understood the part about bitwise operations and truth tables, but after revising my notes, I was confused about their relation to cryptography — although it’s clear that they are some sort of “code,” and that you could encrypt something by turning bits on and off, similar to Morse code.

If we encrypt a message bit by bit, we can create a cipher. Let’s say we want to encrypt the message 1010 using XOR:

Encrypted message: 1100

Now, if we XOR the ciphertext again with the same key:

We get back 1010, the original message.

This is at the heart of symmetric encryption, and XOR is one primitive — a building block of encryption.

2. Hash Functions

After exploring bitwise logic, we then moved on to hash functions.

Hash functions take an input of any length and produce an output of a fixed length. This output is called a digest.

As a software developer, I find hash functions fascinating because I see their fingerprints everywhere:

In Docker, each image has a hash that uniquely identifies its contents.
In JWTs, a hash ensures integrity and trust.
In Git, each commit hash represents a precise snapshot of the code.
In CSS or build artifacts, hashes in filenames help with cache busting by reflecting the file’s exact content.
And of course, passwords should always be stored as hashes.

Hashes are deterministic: the same input always produces the same output.

They are also irreversible: you shouldn’t be able to recover the input from the output.

Finally, they should be collision-resistant, meaning two different inputs should not generate the same output.

In hashing, we also see the Avalanche Effect — a tiny change in the input has a massive effect on the output.

That’s where the Birthday Attack comes in!

It’s about finding two inputs that produce the same hash. Because of the birthday paradox, collisions are easier to find than intuition suggests.

Example:

You only need 23 people in a room for a 50% chance that two share a birthday.

In hashing, this means you don’t need to test all combinations to find a collision. However, with stronger algorithms, as I understand, they are less probable.

This was the first part of the lecture — and one I really enjoyed! I’ll try to summarize the second part later this week.

Cracking Codes (and Scheduling Conflicts): My Intro to Cryptography with the ZK Bootcamp

Dayana Mick — Fri, 03 Oct 2025 13:49:13 +0000

As part of dev3pack, I yearned for the moment when I could participate in the ZK and Privacy Bootcamp. This topic caught my attention when, as a Shefier, I learned about Midnight in the past cohort (14). Midnight is a side chain of the Cardano ecosystem, designed specifically for data protection and privacy. Midnight uses zero-knowledge proofs to strike a balance between the transparency needed in public blockchains and the handling of sensitive data, for example, personal identity. It is built so that developers can create dapps with selective disclosure.

Although the concept of zero-knowledge proofs is not new, this blew my mind, since it was new to me. If you need to prove you are over 18, instead of disclosing all the data in your identity card, the receiving party only gets to know that you are 18: Not your address, not your picture, not your eye color.

However, being a mom, I knew making it to this bootcamp would be difficult: The hours collided with pick up times, or sports activities. Also, many, many people seem to share this interest, and it was quickly filled, so I asked for the recordings.

Yesterday, in the quiet of the night, very elusive to Midnight ;), I got to play the recording. I thought the material would dive directly into ZK Proofs, but it was introductory. It was the introduction to Cryptography given by 0xMilica. Even though I couldn't attend the session live, it was very engaging. She was very passionate about Maths and Cryptography, and her enthusiasm was contagious.

She explained the Cesar Cipher, the Substitution Cipher, and the Vigenère Cipher. The prerequisite was to write the alphabet and number each letter: A ->1, B -> 2, and so on. The Cesar Cipher is about shifting each letter the same number of positions to encrypt the text. So, for example, if you shift by 3 each letter, and want to encrypt the word "HELLO", you would get "Khoor"; if you shift it by 7, it would be "Olssv".

Substitutions are basically when each letter is mapped to another one, so say H-> M, E-> O, L-> S, O -> P. Then HELLO would be encrypted as "MOSSP". This is stronger than the Cesar Cipher, but breakable with frequency analysis.

After that, the topic was the Vigenère Cipher, which I must say I didn't know of, and challenged my mind. It has a key, or word, around which you get different shifts for each letter. For example, if you have the message "hello" and your key is "cat", you're going to repeat the key to match the message's length. So you would have "catca". Then, you will turn the letters into numbers, so matching in the alphabet, as was the prerequisite. So hello would be 8,5,12,12,15. and "catca" would be 3,1,20,3,1. The next step is to add them together, per letter, and if the number is greater than 26, to wrap it (By subtracting 26 until it is smaller than 26).

In this case:

8 + 3 = 11 (k), 5 + 1 = 6 (f), 12 + 20 = 32 Wrap: 32 - 26 = 6 (f), 12 + 3 = 15 (o), 15 + 1 = 16 (p) -> "kffop"

To decrypt, we subtract instead of adding.

This method, the Vigenère Cipher, was considered unbreakable for centuries, until it was finally cracked in the 1800. I found this so interesting that I researched it and will write the next post about it (Spoiler Alert: It can be slightly related to Ada Lovelace ;)).

Watching this episode made my head hurt a little (given I was already suffering from sinusitis), but when I grasped it, it made me happy that it clicked. I am looking forward to finding time to watch the next episode and write the next blog post with an aside from the two characters that cracked this code.

DAO in Web3: What is it?

Dayana Mick — Sat, 19 Jul 2025 22:38:48 +0000

The first time I heard about A DAO, I thought it had some relation to Daoism: a Chinese philosophical tradition and religion. I was trying to understand how this could relate to the blockchain. It turns out I was overcomplicating it, and of course falling into an acronym trap, in which each subculture or profession has some acronyms that are believed to be shared by the whole group, but they aren't. The same thing happened to me when I entered tech and people were talking about PoC, as in "Proof of Concept, and for me it was "People of Color" 🤪.

So, in Web 3, What is a DAO?
DAO stands for Decentralized Autonomous Organization: It is a mechanism to involve people in making decisions about the Blockchain. It allows people to vote for implementing a change or a measure, or against it. But how do you get the right to vote? In some countries, you can vote only if you're an official citizen of the country, and in others, you get to vote in some elections after living a certain number of years in the country. To be able to vote in the DAO, you need to possess what is called a governance token, and some DAOs require people to stake it (lock it in to help secure the network, gaining rewards on it as an incentive). Some DAOS require you to lock your tokens, because they want to avoid vote-flipping, meaning moving their tokens from address to address to cast multiple votes. When participants don't have to stake their tokens, sometimes the way to enable their votes is to take a snapshot of the number of tokens they hold in a certain period of time.

Voters, as I previously mentioned, can vote for the proposal, against it, or delegate their vote to someone else. To delegate your vote, you should trust the participant to whom you are delegating your vote. How do you check if you trust and align with the views of this participant? You check their community contributions and what they have said in their discussions.

Sometimes the proposal is rejected because the quorum is not reached, meaning that there were not enough votes for the proposal to be accepted or rejected.

To make this more illustrative, I will include here an image of the LISK DAO.

Here we can see that the wallet I connected has no governance tokens; therefore, my account has no participatory rights. All proposals are currently inactive, and from the ones we can see on the list, four have been executed, and one did not reach the quorum to be executed.

If we click that proposal, we can see the bubbles showing the major voters and that the quorum was not reached. We also get some information about the proposal: The date in which it was created and how the participants voted. Below, but not in the screenshot, we will find the abstract of the proposal, the motivation, and an action plan for execution.

To recap, a DAO is an organization within a community that enables participatory decision-making. It sounds very cool. However, some questions appear in front of this kind of organization, with no single point of management (decentralized) and which is independent (autonomous). Let's explore some of these:

If the power of voting is granted by holding governance tokens, then the entity that holds more tokens, like a whale, will have a greater voting power, and this could embody a plutocracy. Plutocracy is a system in which the wealthiest exert an outsized influence and wield the greatest power in decision-making, often at the expense of the general population. Because of this, there are some DAOs that do not grant voting power exclusively due to holding governance tokens.

Community is something that is inseparable from a DAO. It helps to make decisions in a non-hierarchical way. However, when many proposals don't reach the quorum, what does this tell us about the community? Or how can this affect the community? Maybe if its just some proposals, and if we look at the timeline it is because people tend to be more disengaged during certain times of the year. However, if this happens regularly, the community might become more apathetic. It can also be that the proposal is not something that interests all token holders, or something they don't want to think about.

Almost every big protocol has a DAO and it is the mechanism by which they make changes to the protocol: Making proposals, getting feedback, and executing on the positively voted proposals. Apart from the plutocracy concern, a positive point from having voting power attached to holding tokens is that the people who are voting have "skin in the game" and therefore are interested in what will happen and in the changes that will or will not take place.

Yet, a token holder does not necessarily equal an expert, so even if they think a change will be better or worse, maybe they are just deciding from a gut feeling.

Another challenge for DAOs is that when there are too many cooks in the kitchen giving their feedback on proposals, it may mean that they may never get implemented.

To recap: DAOs are a way of self-organized communities to decide on changes. Community engagement is important to move forward. However, there are still questions around only prioritizing token holding as a filter for participation, due to plutocracy concerns, knowledge, and getting too much feedback from many people. Currently, DAOs are experimenting with these questions, and that is why there are different kinds of DAOs with different sets of rules.

First Hackathon: Lessons in Chaos, Code & Communication

Dayana Mick — Mon, 09 Jun 2025 16:50:53 +0000

“SheFi propelled me to hackathons.” I read that on SheFi’s landing page and wished I were that person. Now I am. I entered the program in February with a little bit of skepticism. Many of the lectures blew my mind — we learned about L2s, rollups, zero-knowledge proofs, smart contracts, and decentralized AI models. Little by little, the questions I had in my head got some answers and I cleared many gaps: Now I had a lot of theoretical knowledge… but practical? I started taking some Cyphrin Updraft courses and got froggy! In March, before ending the Shefi cohort, I already had my spot confirmed for the upcoming ETH Global Hackathon in Prague, and I was excited. I hadn’t finished my Cyphrin Updraft courses, but decided to head there anyway, also because it was a web2-friendly developer event and inspired by Shefi, I decided that I wouldn’t wait until I felt 100% ready, but that I would go.

The Team

I met my team through a Discord group. A guy contacted me, thinking I was another guy, and I had to explain (chuckle), but after that hiccup,all was pretty clear. We brainstormed some ideas loosely, and finally, on Friday, May 29th, we met at the venue, which by the way, was beautiful. We started as 5, but lost someone, not in a tragic way, but due to alignment: After the first night, he decided to go solo. This was perfectly mature and ok. The rest of us were still a diverse bunch:

Our team was diverse:
– A former professional dancer pivoting into blockchain;
– A computer science dropout turned security auditor;
– A mobile dev student curious about blockchain;
– And me: literature grad, Web2 engineer, now Web3 curious.

The Project: InspectiFi

At 9 pm, we started hacking away on InspectiFi, a conversational blockchain analytics assistant that allows users to ask natural language questions about blockchain data and returns easy-to-understand answers with accessible, easy-on-the-eye dashboards GitHub Project InspectiFy.

InspectiFi leverages MCP technology and integrates with the sponsors 1inch, Blockscout, and Vlayer to provide real-time Blockchain data in an intuitive way.

The Fun

I drank all the Cokes I hadn’t taken in more than 10 years (Thanks, ETH global,l for providing them). I think my team did too. We stayed late, got stressed, wrangled with the code, taught each other stuff, did some pair programming, debugging, fixing merge conflicts, resurrected code from the dead, because it was important, and in the end, won two pool prizes from the sponsors, 1Inch and Blockscout. I wasn’t counting on this, but it made the experience even better. Also, one week later, I’m still blown away by our team: I got to meet incredible people and am still over the moon about that!

If you're heading to your first hackathon, expect chaos, drink water (along with the cokes), and pair up with someone stronger where you're weaker. That’s how we survived.

The Learnings

Big teams = more communication overhead. Plan for it.

Don’t assume shared Git knowledge. Align early.

Set game rules. Spell out collaboration and review norms.

Deploy often. Avoid one giant, sleep-deprived deploy.

Decide what “done” means early (e.g., qualifying for finalists? Then prioritize deploys).

Our Team was great, however, the bigger the team, the more communication overhead you are going to have. I wouldn’t change our team, but this is something I will have in mind for my next project. Even if you say “let’s use branches,” align on how. Show examples, decide how to handle conflicts, and expect different defaults. Drop assumptions and go for clear communication and setting clear game rules from the beginning. And lastly, set rules about deployment: Do you have the goal of entering the finalist competition? Then Do smaller deploys and avoid fighting a huge monster where all issues have been conflated into one and no energy left to fight that monster.

We left Prague with a lot of swag — and even more curiosity.
Next time, I’m showing up with a bigger water bottle, better Git habits, and clear deployment rules. And probably still a Coke.

Thanks, SheFi.

What I Learned During the SheFi Program — And Why I Recommend It

Dayana Mick — Thu, 08 May 2025 20:09:25 +0000

What I Learned During the SheFi Program — And Why I Recommend It

I started my journey into the world of crypto with a lot of doubts. I thought:

"If anything, I’d invest in ETH, not Bitcoin."

But even then, I was concerned about the environmental impact.

Reading more, I discovered that Ethereum had transitioned to a more sustainable consensus mechanism — Proof of Stake (PoS) — unlike Bitcoin's Proof of Work (PoW). That helped ease my conscience a bit.

But that was just the first hurdle.

🛠️ Setting Up: Wallets and Exchanges

I set up my wallet and opened an account on a crypto exchange. That part was fairly smooth — I'm a software engineer, so I know my way around tech.

Still, I found myself uneasy about usability and safety. Crypto addresses are long, unreadable strings, and one wrong character could mean losing your funds forever. We’re all human — and humans make mistakes.

🤯 Trying to Make Sense of the Lingo

The terminology was intimidating:

Second Layer solutions
Why did I have to choose from so many networks when transferring tokens (and the anxiety of losing money with the wrong one!)
What are NFTs, bridges, swapping? Why do they matter, and how do they work?

I kept reading, but I often felt unsure whether I was “getting it right.”

🎓 Enter SheFi: The 13th Cohort

Then I got an invitation to join SheFi’s 13th Cohort — and everything started to make sense.

From the first lecture, things clicked. The program is built around learning by doing, with quests that reinforce every concept.

🔑 What I Learned

Some of my biggest takeaways:

Web2 vs. Web3 (Spoiler: Web3 gives more ownership to users.)
The Blockchain Trilemma: balancing ⚖️ Scalability, 🛡️ Security, and 🕸️ Decentralization
How to mint NFTs
How Swapping, Stablecoins, and Bridging work — and why they matter

💡 Why I Recommend It

If you’re a woman, identify as one, or as a non-binary person, are curious about crypto, overwhelmed by the jargon, or just want a safe, inclusive space to learn and grow —

SheFi is for you.

You don’t need to be an expert. You just need to be open to learning.

🤓 How I will continue Learning and a Funny Story

During the program, I saw that an ETH Hackathon was happening in Prague at the end of May and decided to enroll. I set up my profile, and a guy contacted me to be part of the team. The funny part: They thought I was also a guy 😂. But, yeah, the truth is that in tech there are more guys than women, so how would they know? Anyway, I had to explain that I was a woman. I am looking pretty much forward to this experience and I'll be writing about it here as well.

Some thoughts on DevOps Culture (revisiting a novel from 2013)

Dayana Mick — Thu, 08 May 2025 19:23:21 +0000

I just finished The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford. What can I say?

I listened to it as an audiobook, and it definitely deserves a second listen.

As someone with a literature background who has worked in tech for several years, I was thrilled to come across a novel about IT — yes, a novel. It’s not exactly a literary masterpiece, but it’s highly entertaining if you can relate to the problems it depicts (and I could — at many different levels). Some chapters had me completely hooked, and the characters were surprisingly relatable. I even laughed out loud a few times.

Here are a few first thoughts — especially for anyone working in IT or collaborating closely with IT teams:

Still Relevant, 10+ Years Later

Although the book was first published in 2013 (with an anniversary edition released recently), many of the issues it describes still feel painfully relevant. In the organizations I’ve worked with, some have embraced the “DevOps” mindset more than others, but The Phoenix Project remains a great read for anyone in or around IT.

Let’s Talk About Brent

I’ve met many “Brents” in my career.

Some are knowledge hoarders. Others are what I’d call the “good Brents” — helpful, overextended experts who carry entire systems on their backs. In the book, Brent is a central character: the lead engineer who is everywhere. He’s the go-to person for every urgent issue, the one non-IT people chase down in hallways, and the person everyone relies on... unofficially.

At first, I saw him as a symbol of what’s broken in tech orgs — a bottleneck, a single point of failure, someone who enables dysfunction (often unknowingly). But toward the end, he redeems himself, and in the afterword, the authors even present him as a positive force. That surprised me. I’m still not sure I agree, and I want to reflect on this more during my second listen.

Human Stories in a Tech World

I appreciated the effort to create human characters — to show them as parents, spouses, friends — and how their work lives impacted their home lives. The book shines when it highlights traits beyond just technical skill, surfacing the emotional and human cost of poor systems and leadership.

Why I’ll Listen Again

This first listen already gave me a lot to reflect on. I think a second round will help me dig deeper into the problems and proposed solutions. Maybe I’ll even change my mind about Brent.

In any case, it’s been refreshing to engage with DevOps culture through fiction. For those of us navigating this space, it's a reminder that IT is never just about systems — it’s about people.

Curious About

I read a LinkedIn post in which the author, Gene Kim, tells the world he is co-writing the Book "Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond" which will be released this year. I must confess that while I was reading The Phoenix Project, I was thinking about how AI could change the landscape presented in the book.