[!IMPORTANT] This analysis is based on the information available at the time of the investigation. Unfortunately, the original payload URLs were removed before the primary analysis (if you managed to grab them in time, hit me up!). Therefore, a direct inspection of the actual malicious files was not possible. Hence, the analysis may be incomplete due to missing information about the payload. This analysis delves into the malicious DPRK-built macOS application bundle, 1inch-analysis.app, which targeted Anton Bukov from 1inch. The attack was executed by the fake security researcher Nick L. Franklin. This incident, which is part of a broader deception and exploitation attempt, can be attributed[^1] with high confidence to the AppleJeus/Citrine Sleet/UNC4736 DPRK team. [^1]: See Radiant's incident update here, along with the on-chain link. Additionally, the payloads exhibit distinct pattern matching. Always be paranoid! Directory Structure of 1inch-analysis.app

This blog post was co-authored by Matt, Moody, and Ramana, with additional feedback from Charles. Together, these contributors represent the entire EVM stack, from VM, formal specification and compiler maintainers to application and library developers. You can share your feedback on this blog post in the discussion thread here. This blog post examines the Ethereum Object Format (EOF) proposal — its purported benefits, underlying complexities, and whether its costs truly justify its implementation. We begin with a high-level overview of EOF's design architecture, explore its claimed benefits, and ultimately show that these benefits represent "nice-to-haves" rather than essential improvements to the protocol. Moreover, these improvements could be introduced individually with smaller and simpler changes. Instead, the specific way in which the changes have been bundled together comes with the real cost of significantly increased protocol complexity, which raises the risk of consensus bugs. It also introduces "unknown unknowns", as evidenced by reentrancy considerations that remained undiscovered until four years into its development cycle. Understanding EOF's Design EOF introduces a structured format for EVM code, with its latest specification available here. The design revolves around "containers" that separate code and data whilst allowing flexibility for future container types. EOF introduces subroutine functionality through new opcodes — CALLF, RETF, and (tentatively) JUMPF — which are modeled within the format using containers.

This manifesto was immortalised on-chain: 0x7181be7f573079305316257ef19e8b5cbf553821ebc27845596b305031f3c5ed. Furthermore, this manifesto was Base64 encoded and published via a BLOB-carrying transaction: 0x0112f60d433dc40213731c931bb38377f64e39906f77414583fa9d3eb04274c7. It's 2024. Privacy is facing a severe crisis. Security has never been so fragile as it is today. Censorship resistance is at stake. I'm sitting here writing this manifesto with great concern that we are losing the principles that brought us here. This is an attempt to reunite. To refocus on what is really important. Let's get back to the roots. We, the proponents of Ethereum and the principles of cypherpunk ideology, declare our commitment to the advancement of the core principles privacy, security, and censorship resistance in the digital realm. In the spirit of the original Cypherpunk Manifesto penned by Eric Hughes, we present this manifesto tailored to the ethos of Ethereum.[^1] Our Core Principles Privacy We believe in the fundamental right to privacy as a cornerstone of individual freedom. Privacy is not merely a luxury but a necessity in the digital age, particularly in realms such as communication, finance, voting, healthcare, and identity/reputation, where confidentiality holds pivotal importance. No personal data shall be disclosed without the explicit consent of the data owner. We advocate for the integration of privacy-preserving technologies, such as zero-knowledge proofs, stealth addresses, or homomorphic encryption, into the Ethereum ecosystem, enabling users to transact, interact, and authenticate with confidence and anonymity.

 Special thanks go to Charles Cooper, fubuloubu, banteg, and Tanguy Rocher for feedback and review. gm 🐍snekooors, as you all well know, Vyper is a contract-oriented Pythonic programming language that is targeting the Ethereum Virtual Machine (EVM). But do you guys know about the inner workings of the Vyper compiler itself? This article attempts to shed some light on how the Vyper compiler itself works and delves into the different layers of the compilation phases. Or, in other words, we examine what happens beneath the surface when you have a Vyper contract, e.g. Foo.vy: # @version ^0.3.9 @external @pure

Completeness: Assuming the statement is true & the verifier and the prover are honest, the proof is accepted. Knowledge soundness: If the statement is false, a fraudulent prover cannot convince an honest verifier that it is true except by a tiny probability. Zero-Knowledge: Given that the statement is true, a verifier learns nothing more than the fact that the statement is true. Thus, we get: Zero-Knowledge Proof = I know the secret. I can't tell you the secret. But I can prove to you that I know the secret. References https://taiko.mirror.xyz/9kGUby8h_dyu-t8jcPkDADfbWUMJw3mlGxvZAZk9sV0