alexweb3dev

The difference between Memory and Calldata in function arguments: Calldata is read only, so it can not be modified, the data lives directly in the transaction calldata and it is also the cheapest to use. With memory, the data is copied into memory (duh... :D), it is more expensive than using calldata, but it allows you to modify the data if you wish to do so.

In Solidity, interfaces only declare function signatures, not their implementations, and because of that, most modifiers are not allowed. You can only use modifiers that describe the external ABI: external (this one is required), view, pure and payable. Modifiers related to implementation or internal behavior are not allowed, so you can not use internal, private, virtual, override or custom modifiers like onlyOwner, nonReentrant etc. That is because interfaces can not contain function code, and those modifiers either affect execution of the function or depend on function body code being present.

In what cases could abi.encodePacked create a vulnerability? It can become dangerous when its output is used in cases where each the result must be unique, because the encoding itself does not guarantee that. If the output is used for things like hashing, signing, authentication, authorization or other cases where uniqueness is a requirement, then you should use abi.encode instead, unless every field used in the encoding is of fixed size.

As a general rule, use abi.encode by default and only use abi.encodePacked when all the types have a fixed size and the risk of hash collisions is acceptable

abi.encodePacked encodes the data in a tightly packed form, the values are not padded to 32 bytes and can potentially create hash collisions

In Solidity, abi.encode and abi.encodePacked are both used to serialize data. However, they both do it differently and if you choose the wrong one, you can potentially introduce bugs. abi.encode encodes data using the standard ABI encoding, the output is unambiguous, each value is padded to 32 bytes and it is safe for decoding and using with dynamic types.

Storage collisions can be avoided by using unstructured storage (EIP-1967), leaving storage gaps, thus allowing for future variables to be added without changing storage layout. Also, never reorder variables, only append new variables and keep the inheritance order the same.

A storage collision in a proxy contract occurs when the proxy and an implementation use the same storage slot for different variables. In Ethereum, state variables are stored in fixed storage slots (0, 1, 2...). When a proxy contract calls an implementation contract using "delegatecall", the code of the implementation will be executed in the proxy's context (affecting the proxy's storage variables). If the proxy and implementation contracts do not agree on which slots are used for which variable, it can lead to serious security vulnerabilities.

This can cause big problems if not handled correctly, so if protocols want to support fee on transfer tokens they have to account for this behavior when designing their system.

Most DeFi protocols assume that balanceAfter = balanceBefore + amount, but for fee on transfer tokens it is balanceAfter = balanceBefore + (amount - fee).

A fee-on-transfer token is like an ERC-20 token that charges a fee every time it is transferred. When a transfer takes place, the token contract deducts a fee from the amount to be sent and sends only the remaining amount to the recipient, while sending the fee to a destination address (e.g. a treasury).

Privacy matters: (another very long tweet) I'm trying to explain the difference between TEE, ZK, MPC and FHE. If we're talking privacy, security and blockchains, this is important to understand. Last time I explained TEE, today I'll explain ZK: 📚 ZK stands for Zero Knowledge. Among the technologies I’m surveying (TEE, ZK, MPC, FHE) it's the most mature and battle tested one in blockchain settings. - @Zcash has been using ZK for privacy since we launched it in 2016 (the whitepaper we wrote on which it's based is from 2014). - @StarkWareLtd has settled over $1.4T on STARK technology since 2020, scaling Ethereum and Bitcoin, and saving users over $1B in transaction fees. Why am I mentioning this? Because no other technology surveyed here is as battle-tested and used as ZK. ZK has two super-powers: Privacy and Scalability. How does it work? There are two types of entities: A ZK prover and a ZK verifier. There is a separation of powers between them. 1. The prover does the heavy lifting -- it collects the data about all relevant txs, processes them, updates the state of the system based on these txs, and spits out a statement, and a proof. - A typical statement says "I, the prover, have started with state A, processed 1,000,000 transactions, and based on those, reached state B". - The proof is a short sequence of numbers and hashes that *proves* the integrity of the whole statement. 2. The verifier checks the proof to see if it's valid for that particular statement. The verifier typically sits onchain. The way a verifier works is by using math and cryptography, and I won’t explain it here. But suffice to say that the theorems we’ve proved about ZK over the years say that the verifier always accepts true statements and never accepts false statements (more precisely -- a malicious prover who wants to convince a verifier to accept a false statement has to do a similar amount of work to finding a collision in a cryptographic hash function, which cannot be done before our Sun cools down). Once the verifier checked the proof, the statement can be accepted. ZK is really good for allowing a single user to shield their data, and for scaling blockchains. Privacy is what we used it for on Zcash, and Scalabilty is what we (and, following us, others) use it at StarkWare. Note: ZK also has a safe, ergonomic and efficient smart contract language (Cairo). Developers can write and execute any smart contract offchain and guarantee its integrity onchain. You can write programs in Cairo (and in other languages) that you can prove in ZK. Challenges: - When it comes to UX and composability of smart contracts, it gets messy. - When there’s a computation that involves confidential data from more than one user, ZK isn’t good at solving it. For that you have to use a generalization of ZK called secure Multi Party Computation (MPC, I'll explain that too). Not impossible, but requires work. Next time: MPC. The END.

Promoted to Gold League in @_MathAcademy_. Platinum League soon! 💪🫡

There’s only one path to greatness - the grind. At some point, you’ll find yourself standing between two versions of you your old self, full of comfort and familiarity, and your new self, chasing something extraordinary. It’s tempting to go back. Back to the simple joys, the easy wins, the comfort of being 'good enough.' But once you’ve seen the other side once you’ve glimpsed what greatness looks like, you can’t unsee it. The only way is forward. It’s the same in engineering. Once you understand how Arc and Mutex really work in Rust, or how Kubernetes orchestrates systems with surgical precision you can’t go back to 'just writing scripts' or 'running apps locally.' You’ve seen the deeper layers. You’ve seen how things really work. It’s not an easy path. But that’s the price of mastery once you’ve tasted depth, comfort becomes the enemy. Keep moving forward. The grind isn’t punishment, it’s transformation. Once you have seen the top, you can't help moving forward. And that's where the crazy fun is, to conquer something that's out of your reach right now.

Legacy isn’t built from ambition, it’s built from mastery. Been reading a lot of @justinskycak posts lately, and it completely changed how I think about memory and recall. If you want to create something truly new, you have to become dangerously good at the fundamentals. We chase complex stuff so fast that we forget to revisit and recall the basics. But spaced repetition and active recall are what build the deep layers of understanding that unlock higher levels of abstraction where true creativity actually lives. Mastery is about remembering better. Not necessarily learning more. When I started learning Rust, I kept rushing to advanced concepts - async, lifetimes, ownership but it was when I slowed down, practiced spaced recall, and revisited the fundamentals that it all clicked. The deeper I went, the more creative my code became.

Code, test, deploy, refactor, and verify. Read, audit, fork, innovate, document, and teach. Study systems, protocols and incentives. Say no to hype and noise. Avoid exploits, debt, complacency and shortcuts. Relax. Victory is assured.

Whatever skills are fundamental in your domain, you need to develop as strong a command over them as a musician’s command over their instrument, or a gymnast’s command over their body. That takes a massive amount of consistent practice over a long period of time – which is hard, which is why most people don’t do it, which is why you get such an outsized competitive advantage if you do.

Study math. Study philology. Study physics. Study psychology. Study behavioural sciences. Study human relationships. Just study everyday. It's not something you only do in high school or in university - it must be your way of life, it's the formula you've been looking for🫡