[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-ethereum-wikipedia-dev-cheat-sheet-en":3,"article-related-ethereum-wikipedia-dev-cheat-sheet-en":30,"series-research-f05d7971-4858-4384-81d8-00299b99ed17":76},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"f05d7971-4858-4384-81d8-00299b99ed17","ethereum-wikipedia-dev-cheat-sheet-en","Ethereum turns Wikipedia into a dev cheat sheet","\u003Cp data-speakable=\"summary\">I turn Wikipedia’s \u003Ca href=\"\u002Ftag\u002Fethereum\">Ethereum\u003C\u002Fa> page into a copy-ready dev cheat sheet.\u003C\u002Fp>\u003Cp>I've been around Ethereum long enough to be annoyed by how often people explain it like it’s either magic money or a science project nobody can touch. That’s not how I use it. When I’m trying to explain Ethereum to another developer, I don’t want the glossy version. I want the part where the mental model clicks: what the chain actually does, why smart contracts matter, why gas exists, and why the shift to proof-of-stake changed the whole operating cost of the network.\u003C\u002Fp>\u003Cp>What kept bugging me is that most summaries stop at “decentralized blockchain with smart contracts” and then sprint off into \u003Ca href=\"\u002Ftag\u002Ftoken\">token\u003C\u002Fa> hype. That’s useless if you’re trying to build, debug, or even just decide whether Ethereum is the right substrate for a product. I ended up going back to the source that everybody can read but almost nobody actually decomposes well: the \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FEthereum\">Ethereum Wikipedia page\u003C\u002Fa>. It’s not perfect, but it’s packed with the core facts, the historical pivots, and the design constraints that matter.\u003C\u002Fp>\u003Cp>So I’m going to strip it down the way I wish someone had done for me: no ceremony, no crypto theater, just the parts that affect architecture and product decisions.\u003C\u002Fp>\u003Ch2>Ethereum is not “a coin,” it’s a runtime with a token attached\u003C\u002Fh2>\u003Cblockquote>“Ethereum is a decentralized blockchain with smart contract functionality. Ether (abbreviation: ETH) is the native cryptocurrency of the platform.”\u003C\u002Fblockquote>\u003Cp>What this actually means is simple: Ethereum is the machine, ETH is the fuel. People talk about ETH like the whole thing, but the chain itself is the point. The blockchain stores state, executes contracts, and lets anyone deploy applications that other people can use without asking a central operator for permission.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782152297559-pocz.png\" alt=\"Ethereum turns Wikipedia into a dev cheat sheet\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>I’ve seen teams get this backwards all the time. They start with “we need a token” and only later ask what the network is for. That’s how you end up with a wallet-shaped product with no real utility. Ethereum’s design starts from the other side: shared execution first, asset layer second.\u003C\u002Fp>\u003Cp>The Wikipedia page also makes an important distinction that gets lost in casual discussion: Ethereum is open-source software. That matters because the protocol is not a black box hosted by one company. The implementation is public, and the ecosystem has always depended on multiple clients and independent contributors. If you want the canonical project site, start with \u003Ca href=\"https:\u002F\u002Fethereum.org\">ethereum.org\u003C\u002Fa>. If you want the code-level ecosystem, the main client family begins with \u003Ca href=\"https:\u002F\u002Fgeth.ethereum.org\u002F\">Geth\u003C\u002Fa>, the Go implementation.\u003C\u002Fp>\u003Cp>How I apply this in practice: when I describe Ethereum to a product team, I avoid saying “we’ll build on crypto.” I say, “we’ll build on a shared execution layer and settle value in ETH if needed.” That framing keeps the conversation about architecture, not speculation.\u003C\u002Fp>\u003Cul>\u003Cli>Use Ethereum when you need shared state that multiple parties can verify.\u003C\u002Fli>\u003Cli>Don’t use it just because you want a token on a slide.\u003C\u002Fli>\u003Cli>Separate the application idea from the asset idea early.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Vitalik’s original pitch was about apps, not payments\u003C\u002Fh2>\u003Cp>The page traces Ethereum back to Vitalik Buterin’s 2013 white paper and his argument that blockchain could do more than money. That’s the part I think a lot of people miss when they treat Ethereum as “Bitcoin, but different.” Buterin wanted a more expressive language for application development, and the Wikipedia entry even notes the push toward a Turing-complete scripting model.\u003C\u002Fp>\u003Cp>That sounds academic until you think about what it buys you. A limited transaction system can move value. A general-purpose execution environment can encode logic: escrow, auctions, lending rules, governance, collectibles, access control, and all the ugly edge cases in between. That is the real reason Ethereum became the default reference point for smart contracts.\u003C\u002Fp>\u003Cp>I ran into this distinction hard when I was evaluating whether a workflow should live on-chain. If all I needed was a ledger, the chain was overkill. If I needed programmable enforcement between parties that didn’t fully trust each other, then the chain started to make sense. Ethereum’s origin story is useful because it tells you what kind of problems it was built to absorb.\u003C\u002Fp>\u003Cp>The source page also names the early founders: Vitalik Buterin, Gavin Wood, Charles Hoskinson, Anthony Di Iorio, and Joseph Lubin. That matters because the network didn’t emerge from a single product team with a single roadmap. It grew out of a messy, multi-founder, multi-implementation effort. That mess is part of why the ecosystem is so broad now.\u003C\u002Fp>\u003Cp>How to apply it: \u003Ca href=\"\u002Fnews\u002Fprompt-engineering-pay-gets-real-when-you-ship-systems-en\">when you\u003C\u002Fa>’re deciding whether a system belongs on Ethereum, ask one question before anything else: does the application need shared, verifiable logic across parties who may not trust one operator? If the answer is no, stop romanticizing the chain.\u003C\u002Fp>\u003Cul>\u003Cli>Ethereum is strongest when logic, not just data, needs to be shared.\u003C\u002Fli>\u003Cli>Smart contracts are about enforcement, not just automation.\u003C\u002Fli>\u003Cli>General-purpose execution is the feature, not the token price.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>The Yellow Paper is the boring document that made the thing real\u003C\u002Fh2>\u003Cp>Wikipedia points out that Gavin Wood wrote the Ethereum Yellow Paper, which specified the Ethereum Virtual Machine. This is the kind of detail that gets skipped in hype posts, but I think it’s one of the most important parts of the whole story. Ideas are cheap. Precise execution rules are what make a platform usable by strangers.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782152293614-3haj.png\" alt=\"Ethereum turns Wikipedia into a dev cheat sheet\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>The EVM is the heart of Ethereum’s compatibility story. It defines how code runs, how state changes, and what a transaction means. If you’ve ever debugged a contract and wondered why a call reverted, why gas was eaten, or why a seemingly harmless change broke compatibility, you’ve already felt the consequences of the EVM’s exactness.\u003C\u002Fp>\u003Cp>I’ve had to explain this to backend engineers who expected blockchain execution to behave like a normal service call. It doesn’t. On Ethereum, execution is constrained, metered, and replicated across nodes. That makes it dependable in one sense and annoying in another. You don’t get to shrug off state changes. Everyone verifies them.\u003C\u002Fp>\u003Cp>If you want the technical foundation, the Ethereum docs at \u003Ca href=\"https:\u002F\u002Fethereum.org\u002Fen\u002Fdevelopers\u002Fdocs\u002F\">ethereum.org\u002Fen\u002Fdevelopers\u002Fdocs\u002F\u003C\u002Fa> are the right place to start. If you want a concrete client implementation, the Geth repository is here: \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fethereum\u002Fgo-ethereum\">github.com\u002Fethereum\u002Fgo-ethereum\u003C\u002Fa>. Those are the references I use when I need to move from “concept” to “how this actually runs.”\u003C\u002Fp>\u003Cp>How to apply it: don’t design contracts like you’re writing a normal \u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa>. Design them like you’re writing a public machine specification. Every branch, every storage write, every external call has to survive hostile execution and public replay.\u003C\u002Fp>\u003Ch2>Gas is the bill you pay for making computation public\u003C\u002Fh2>\u003Cp>The Wikipedia article includes gas as one of the core design elements, and I think that’s where most newcomers finally realize Ethereum is not just a database with a trendy logo. Gas exists because computation on a shared network is expensive and needs metering. If a transaction can consume arbitrary resources, the whole system becomes easy to abuse.\u003C\u002Fp>\u003Cp>What this actually means is that every operation has a cost. Storage costs more than computation in many cases. Complex contract paths cost more than simple ones. Badly written code doesn’t just run slower, it can become economically unusable. That’s not a side detail. That’s the architecture.\u003C\u002Fp>\u003Cp>I’ve seen teams ship contracts that were technically correct but economically dumb. They added extra writes, unnecessary loops, or overly chatty contract calls, then acted surprised when users complained about fees. On Ethereum, “works” and “is worth using” are not the same thing.\u003C\u002Fp>\u003Cp>This is also why the ecosystem cares so much about tooling and audits. You’re not just checking logic. You’re checking whether the logic makes sense under a fee model that punishes waste. If you’re building on Ethereum, you need to think in terms of gas budgets the way backend teams think in terms of latency budgets.\u003C\u002Fp>\u003Cp>How to apply it: before you deploy anything, estimate the cost of your most common user path. Then simplify it. If you can move a check off-chain, batch writes, or reduce storage churn, do it. Ethereum is not the place to be casual about resource use.\u003C\u002Fp>\u003Cul>\u003Cli>Gas is a defense mechanism against abuse.\u003C\u002Fli>\u003Cli>High storage usage is expensive for a reason.\u003C\u002Fli>\u003Cli>Every contract should be reviewed for economic as well as logical efficiency.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>The Merge changed the energy story and the operating model\u003C\u002Fh2>\u003Cp>The page says Ethereum transitioned from proof-of-work to proof-of-stake on 15 September 2022 in an update called “The Merge,” and that it cut energy usage by over 99%. That’s not a cosmetic change. It altered how the network secures itself, how validators participate, and how people talk about the chain’s footprint.\u003C\u002Fp>\u003Cp>What this actually means for builders is that Ethereum stopped depending on miners in the old sense and moved to validators staking ETH. The consensus model changed, and with it the economics of participation. If you were still mentally modeling Ethereum as a mining network after 2022, you were already behind.\u003C\u002Fp>\u003Cp>I remember how often proof-of-work got dragged into every Ethereum conversation, especially by people trying to dismiss the platform on environmental grounds. The Merge didn’t magically solve every criticism, but it did remove one of the biggest objections. That matters if you’re trying to justify a deployment to stakeholders who care about energy use or long-term network sustainability.\u003C\u002Fp>\u003Cp>For the canonical explanation of the transition, I’d point people to the Ethereum Foundation’s material and the broader docs on \u003Ca href=\"https:\u002F\u002Fethereum.org\u002Fen\u002Froadmap\u002Fmerge\u002F\">The Merge\u003C\u002Fa>. That’s the kind of source I trust when I’m trying to separate protocol change from internet mythology.\u003C\u002Fp>\u003Cp>How to apply it: if your mental model of Ethereum still depends on mining, update it. And if you’re evaluating the chain for a product, factor in that the consensus story is now staking-based, not hashpower-based. That changes who participates and how incentives are structured.\u003C\u002Fp>\u003Ch2>NFTs, DeFi, and ERC standards are where Ethereum got messy and useful\u003C\u002Fh2>\u003Cp>Wikipedia lists ERC-20 tokens, NFTs, and decentralized finance as major application areas. This is where Ethereum stopped being just an experiment and became a platform that other people could build on in ways nobody had fully predicted. ERC-20 made fungible tokens interoperable. ERC-721 made non-fungible tokens a standard instead of a one-off hack. \u003Ca href=\"\u002Ftag\u002Fdefi\">DeFi\u003C\u002Fa> turned contracts into financial plumbing.\u003C\u002Fp>\u003Cp>That interoperability is the real trick. Standards mean wallets, exchanges, marketplaces, and apps can support the same asset shape without rewriting everything from scratch. That’s why Ethereum became the default home for token experiments and financial primitives.\u003C\u002Fp>\u003Cp>I’ve worked on systems where the lack of a shared standard was the whole problem. Every integration became custom. Every new asset type meant another adapter. Ethereum’s standards reduced that friction, even if they also opened the door to a lot of junk. Both things are true at the same time.\u003C\u002Fp>\u003Cp>If you want to see the standards themselves, the Ethereum Improvement Proposal system is the place to look: \u003Ca href=\"https:\u002F\u002Feips.ethereum.org\u002F\">eips.ethereum.org\u003C\u002Fa>. For ERC-20 specifically, start with \u003Ca href=\"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-20\">EIP-20\u003C\u002Fa>, and for NFTs, \u003Ca href=\"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-721\">EIP-721\u003C\u002Fa>. Those specs are more useful than a thousand “\u003Ca href=\"\u002Ftag\u002Fweb3\">Web3\u003C\u002Fa>” explainers.\u003C\u002Fp>\u003Cp>How to apply it: if you’re building assets or contracts that need to be recognized by external tools, follow the standard instead of inventing your own format. Interoperability is the whole point. If nobody else can parse what you made, you’ve probably built a private toy, not a platform feature.\u003C\u002Fp>\u003Ch2>Ethereum’s history is basically one long argument about tradeoffs\u003C\u002Fh2>\u003Cp>The Wikipedia history section reads like a sequence of tradeoffs getting made in public. Founding debates, crowd sales, multiple client implementations, the DAO exploit, the hard fork, the split with Ethereum Classic, the Enterprise Ethereum Alliance, then later the Merge. It’s not a tidy story. That’s why it’s useful.\u003C\u002Fp>\u003Cp>What this actually means is that Ethereum was never just a codebase. It was a governance problem, a security problem, a coordination problem, and an ecosystem problem all at once. The DAO fork alone is enough to tell you that “immutability” sounds cleaner in a slide deck than it does in a crisis.\u003C\u002Fp>\u003Cp>I think the DAO event is one of the most important lessons in the entire history of Ethereum. The network had to choose between preserving one interpretation of ledger immutability and reversing a major theft. The result was a split chain. That’s not a bug in the history. It’s the history.\u003C\u002Fp>\u003Cp>For developers, the takeaway is blunt: if you build on Ethereum, you are building inside a system with social and technical governance. Protocol upgrades happen. Hard forks happen. Consensus can change. Pretending otherwise is how teams get blindsided.\u003C\u002Fp>\u003Cp>How to apply it: read protocol history before you deploy anything long-lived. Know how upgrades are handled. Know how the ecosystem responds to catastrophic bugs. And if your product depends on absolute continuity, make sure you understand the governance layer, not just the contract layer.\u003C\u002Fp>\u003Ch2>The template you can copy\u003C\u002Fh2>\u003Cpre>\u003Ccode># Ethereum, explained for developers\n\nEthereum is a decentralized blockchain with smart contract functionality.\nETH is the native asset, but the real product is the execution layer.\n\n## What it is\n- Shared state machine\n- Public contract execution\n- Open-source protocol with multiple clients\n- Asset layer for ETH, ERC-20 tokens, NFTs, and more\n\n## Why it matters\n- Lets multiple parties verify the same logic\n- Supports programmable assets and contracts\n- Uses gas to meter public computation\n- Moved from proof-of-work to proof-of-stake with The Merge\n\n## When to use it\nUse Ethereum when:\n- You need shared, verifiable logic\n- More than one party must trust the same rules\n- Asset standards and wallet support matter\n- Public settlement is part of the product\n\nDo not use Ethereum when:\n- You just need a database\n- A single operator can run the system better\n- You need cheap, high-throughput private writes\n- Tokenization is the only reason you’re considering it\n\n## Core mental model\n1. The chain is the runtime.\n2. ETH pays for execution.\n3. Gas limits abuse and waste.\n4. Smart contracts are public machine code.\n5. Standards like ERC-20 and ERC-721 make assets interoperable.\n6. Consensus changed to proof-of-stake.\n\n## Practical checklist before building\n- Define the trust model first\n- Estimate gas for the common path\n- Decide what must live on-chain\n- Use established standards unless you have a very good reason not to\n- Read the protocol history so you know how upgrades and forks affect you\n\n## Copyable explainer for a team doc\nEthereum is a public execution layer for applications that need shared, verifiable rules.\nETH is the native asset used to pay for computation and state changes.\nIf the app does not need shared trust, public settlement, or contract composability, Ethereum is probably the wrong tool.\n\n## Useful references\n- Ethereum: https:\u002F\u002Fethereum.org\n- Wikipedia source: https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FEthereum\n- Geth: https:\u002F\u002Fgeth.ethereum.org\u002F\n- EIPs: https:\u002F\u002Feips.ethereum.org\u002F\n- The Merge: https:\u002F\u002Fethereum.org\u002Fen\u002Froadmap\u002Fmerge\u002F\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>If I were dropping this into a team wiki, I’d keep the explanation short and the checklist blunt. That’s the whole point: make the decision fast, then move on to the actual architecture work.\u003C\u002Fp>\u003Cp>What I’ve copied here is my own breakdown of the Wikipedia page, not a verbatim rewrite. The source of truth I started from is \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FEthereum\">https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FEthereum\u003C\u002Fa>, and the linked Ethereum docs, EIPs, and client repos are the places I’d use next if I were building or reviewing anything serious.\u003C\u002Fp>","A developer’s breakdown of Ethereum’s design, history, and use cases, with a copy-ready template for explaining it cleanly.","en.wikipedia.org","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FEthereum",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782152297559-pocz.png","research","en","cfe36fb5-68ec-480a-a9be-04660e360468",[17,18,19,20,21],"ethereum","smart-contracts","evm","gas","proof-of-stake",[23,24,25],"Ethereum is a runtime for shared execution, not just a coin.","Gas, standards, and consensus changes shape how you build on it.","The best way to explain Ethereum is to separate the chain, the token, and the contract model.",0,"2026-06-22T18:17:50.367827+00:00","2026-06-22T18:17:50.36+00:00","3103988e-c4fe-45e3-98ab-846500c9d507",{"tags":31,"relatedLang":35,"relatedPosts":39},[32,33],{"name":17,"slug":17},{"name":34,"slug":18},"smart contracts",{"id":15,"slug":36,"title":37,"language":38},"ethereum-wikipedia-dev-cheat-sheet-zh","Ethereum 把 Wikipedia 變開發者速查表","zh",[40,46,52,58,64,70],{"id":41,"slug":42,"title":43,"cover_image":44,"image_url":44,"created_at":45,"category":13},"7b888d1b-5890-4f27-b580-f8bb958ea5a2","teampcp-supply-chain-ai-poisoning-en","TeamPCP供应链投毒暴露AI攻击升级","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782162171698-7dpn.png","2026-06-22T21:02:23.140079+00:00",{"id":47,"slug":48,"title":49,"cover_image":50,"image_url":50,"created_at":51,"category":13},"8047afc9-35a3-4ad1-8e62-2a8881027bc3","anthropic-robodog-test-physical-agentic-ai-en","Anthropic’s robodog test shows physical agentic AI is arriving","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782136968972-srd9.png","2026-06-22T14:02:22.977364+00:00",{"id":53,"slug":54,"title":55,"cover_image":56,"image_url":56,"created_at":57,"category":13},"354441d5-652c-4658-a446-14f101f5e084","rootly-benchmark-llama-4-trails-coding-models-en","Rootly benchmark: Llama 4 trails coding models","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782086567786-wz4t.png","2026-06-22T00:02:22.751682+00:00",{"id":59,"slug":60,"title":61,"cover_image":62,"image_url":62,"created_at":63,"category":13},"569999a1-0afb-46a6-929a-2c9089682668","8tai-jiqiren-ziji-zuo-shiyan-en","8台机器人怎么自己做实验","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782073087231-rcfn.png","2026-06-21T20:17:41.340146+00:00",{"id":65,"slug":66,"title":67,"cover_image":68,"image_url":68,"created_at":69,"category":13},"8cdb1cdd-1014-4c4c-9ea3-63dc78301524","xtragpt-paper-revision-human-ai-collaboration-en","XtraGPT lets you revise papers with control","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782066795284-78ju.png","2026-06-21T18:32:49.655317+00:00",{"id":71,"slug":72,"title":73,"cover_image":74,"image_url":74,"created_at":75,"category":13},"40d7a637-c770-47b5-8813-fd56a798b332","skill-to-lora-cuts-agent-token-overhead-en","Skill-to-LoRA cuts agent token overhead","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781993875444-u3le.png","2026-06-20T22:17:31.1477+00:00",[77,82,87,92,97,102,107,112,117,122],{"id":78,"slug":79,"title":80,"created_at":81},"a2715e72-1fe8-41b3-abb1-d0cf1f710189","ai-predictions-2026-big-changes-en","AI Predictions for 2026: Brace for Big Changes","2026-03-26T01:25:07.788356+00:00",{"id":83,"slug":84,"title":85,"created_at":86},"8404bd7b-4c2f-4109-9ec4-baf29d88af2b","ml-papers-of-the-week-github-research-desk-en","ML Papers of the Week Turns GitHub Into a Research Desk","2026-03-27T01:11:39.480259+00:00",{"id":88,"slug":89,"title":90,"created_at":91},"87897a94-8065-4464-a016-1f23e89e17cc","ai-ml-conferences-to-watch-in-2026-en","AI\u002FML Conferences to Watch in 2026","2026-03-27T01:51:54.184108+00:00",{"id":93,"slug":94,"title":95,"created_at":96},"6f1987cf-25f3-47a4-b3e6-db0997695be8","openclaw-agents-manipulated-self-sabotage-en","OpenClaw Agents Can Be Manipulated Into Failure","2026-03-28T03:03:18.899465+00:00",{"id":98,"slug":99,"title":100,"created_at":101},"a53571ad-735a-4178-9f93-cb09b699d99c","vega-driving-language-instructions-en","Vega: Driving with Natural Language Instructions","2026-03-28T14:54:04.698882+00:00",{"id":103,"slug":104,"title":105,"created_at":106},"a34581d6-f36e-46da-88bb-582fb3e7425c","personalizing-autonomous-driving-styles-en","Drive My Way: Personalizing Autonomous Driving Styles","2026-03-28T14:54:26.148181+00:00",{"id":108,"slug":109,"title":110,"created_at":111},"2bc1ad7f-26ce-4f02-9885-803b35fd229d","training-knowledge-bases-writeback-rag-en","Training Knowledge Bases with WriteBack-RAG","2026-03-28T14:54:45.643433+00:00",{"id":113,"slug":114,"title":115,"created_at":116},"71adc507-3c54-4605-bbe2-c966acd6187e","packforcing-long-video-generation-en","PackForcing: Efficient Long-Video Generation Method","2026-03-28T14:55:02.646943+00:00",{"id":118,"slug":119,"title":120,"created_at":121},"675942ef-b9ec-4c5f-a997-381250b6eacb","pixelsmile-facial-expression-editing-en","PixelSmile Framework Enhances Facial Expression Editing","2026-03-28T14:55:20.633463+00:00",{"id":123,"slug":124,"title":125,"created_at":126},"6954fa2b-8b66-4839-884b-e46f89fa1bc3","adaptive-block-scaled-data-types-en","IF4: Smarter 4-Bit Quantization That Adapts to Your Data","2026-03-31T06:00:36.65963+00:00"]