Dapp-Learning

An online open-source developer community focusing on Ethereum & Layer2.
Official website:

[Dapp-Learning @Dapp_Learning]

经过社区小伙伴的精心整理，在Pop-X HK Researcher House活动上采访@VitalikButerin 的视频和文章终于出炉了。
文章链接：https://t.co/I4QEvKwRg4
Bilibili: https://t.co/ARrK6Xw0AF
视频(youtube)：https://t.co/PLAr8Dfn8l

[蓝狐 @lanhubiji]

从视频看，Tom Lee回应了vitalik之前关于以太坊基金会专注于核心CROPS的帖子，他表示：

“以太坊DAT财库公司，包括 Bitmine 和 Sharplink 在内的财库——现在拥有 7% 的以太坊供应量……财库股票本质上是永久从生态系统中移除的供应量，但我们也拥有收益。收益大约为 3%，因此如今这些公共财库正在产生约 5 亿美元的奖励，这就是我们可以用来资助和资助加密生态系统的东西。”

简单来说，以太坊生态以后不用只靠基金会发钱了，现在这些DAT财库公司，可以拿出钱来支持项目、开发者、基础设施。

主要几点：

1. DAT财库公司已经囤了很多 ETH
像 Bitmine（Tom Lee ）和 SharpLink 等上市公司，现在合计持有全网约 7% 的以太坊。这些公司把 ETH 当成“公司财库”长期持有。

2. 他们靠 staking 每年赚不少。把 ETH 质押到以太坊���络上帮忙维护安全，每年能赚约 3% 的收益。目前这些公司加起来，一年能拿到 约 5 亿美元 的以太坊奖励。

3. Tom Lee 认为，这些钱不要全留着，可以拿出一部分来资助以太坊生态（发 grant、支持项目、开发者、L2 等）。
以前主要靠 以太坊基金会（EF） 出钱，现在这些“DAT财库”也可以自己出钱了。

4. Tom Lee 认为以太坊基金会把重点缩小到最核心的事（CROPS：抗审查、开放、隐私、安全）是正确的决定。

因为以太坊现在已经很大了：
• 市值约 2400 亿美元
• 运行 11 年零宕机
• 全球 89 个国家、11500 个节点
• 15000 个开发者

一个基金会管不过来，未来更多事情要靠私营公司去做。

因为这代表以太坊生态的资金模式在进化：从“靠基金会财库”转向“靠市场化的大持有者自己赚钱反哺”。

这才是实现正向循环该做的事情。

[vitalik.eth @VitalikButerin]

Some of my perspective on where the @ethereumfndn is going.

First of all, this is only my own view. The board is not just me, and I have no extra special powers on the board that the other board members do not. @aerugoettinea is the one executing much of this transition. My input has been largely on technical questions. The board is in the process of expanding, and my own power within the org will continue to decrease, which is honestly what I want.

The 2025 era brought many important improvements to EF and its ability to execute. Many issues were resolved, and EF continues to benefit from its improved efficiency and greater focus on concrete goals to this day. And so with those problems resolved, early this year, the largest remaining hole that I perceived was something different nagging at me: I would regularly spot people saying things like "vitalik says these beautiful things about ethereum needing to be decentralized, and have privacy, and be a sanctuary technology, but why do the EF's actions not reflect that?"

Now, you may have been hearing something different. You may not have been sensing a feeling of crisis at all, and maybe were hearing people saying that finally we were taking execution and BD seriously and the main task for us is to keep going that way and be even better and faster. Then probably there is genuine difference between you and me, in what kinds of criticism I take most seriously, and what kinds of critics through their criticism are most able to make me feel pain.

As an analogy, let's briefly switch over to a different domain.

One belief you can have about Google is that it is a success story, and has brought a lot of good to humanity in organizing the world's information. Another belief you can have about Google is that they had a beautiful idealistic beginning, but at some point the corruption of mainstream corporate attitudes seeped in, and they slowly bit by bit completely abandoned the "don't be evil" slogan.

My belief on Google specifically is probably somewhere between the two. BUT, if you had taken me back in time to ~2008, and offered me a button to press to make Google one or two standard deviations more "dogmatic", eg. give Richard Stallman permanent veto power over some key policies, I would immediately press it.

Why? Because a choice for one company is not a choice for the world, or even one country. Google existed and exists in the context of a technology industry generally drifting away from early idealistic don't-be-evil roots and toward greed for financial gain, totalizing visions of accelerated superintelligence, infiltration by sociopaths, and craven capitulation to (or worse, active participation in) government pressure for ideological control, surveillance and war. And so *one company* doing something different, positioning itself to be what George Bernard Shaw calls the Unreasonable Man, resisting the trend of the times, would have been better for freedom, balance of power and stability of society as a whole, than *all* large companies bending to dominant trends. This is a part of my version of pluralism.

This line of thinking is not just mine, but I also is not too far off from what Aya and others had in mind with the Mandate.

Now how does this all get to the role of the EF?

EF is not a "center of Ethereum", rather EF is "one node, with a defined purpose, alongside other nodes". We've always said that the EF should be the latter, but many in the Ethereum ecosystem (and even within the EF) wanted us to be the former. Now, we are taking action to ensure that we will be the latter.

This is particularly important because EF is a limited organization, with limited resources and limited organizational capacity. The EF has only ~0.16% of all ETH (less than many other individual ETH holders), whereas among other blockchains it's common for "the central foundation" to have 10-50%. Fiscally, the EF was originally designed to fulfill a limited work scope defined in the token sale docs and other pre-launch materials (building the chain software; getting through Frontier, Homestead, Metropolis, Serenity), which was fully completed in 2022; it was not designed to be an eternal steward.

And so today, the EF is choosing to use its remaining resources to pursue longevity over breadth (yes, this means we sell less ETH). The EF focuses *specifically* on those activities critical to the success of ethereum as a censorship/capture-resistant, open, private and secure system, that would not happen otherwise. This means making hard choices, and in some cases even activities that we highly approve of and people that we highly respect becoming outside of the EF. People of great technical talent, public respect and even alignment with the mission and CROPS being outside of the EF is in fact necessary if we want important tasks to be able to attract outside capital. This also means the EF taking opinionated stands culturally.

This is all intended in cooperation with all other parts of ethereum. We recognize that many other parts of the ethereum world highly respect CROPS and related values. But highly respecting is not the same as choosing to specialize and totally dedicate to a domain (Compare in a different domain: I think reducing animal cruelty is important, and I like vegan food, but am not full unconditional vegan myself)

EF is still in a transition period, and we expect its new long-term form to stabilize over the next few months. What are the guiding principles of this new form? Again, I am only one person, but I can give my answer from a technical perspective (there are also critical non-technical aspects).

At the core, *Ethereum must be impressive*. We are living in an age of highly intelligent AI and all kinds of other technological acceleration. "Status quo EVM, with a hard fork or two a year to optimize for short-term needs of users" is not interesting.

To some, "impressive" means: 250ms latency and 1M TPS. I think Ethereum trying to go that route is a mistake. Being as fast and as scalable as possible, and only a small epsilon more decentralized than the others, is a route to mediocrity, and if we try it we will lose.

I think Ethereum should scale. But I think Ethereum should strive the hardest to be deeply impressive in a different dimension: the CROPS dimension. This means things like:

* Provably bug-free Ethereum. This is a goal that all cybersecurity researchers would have thought is absurd and impossible, up until roughly 6 months ago. Now, it's on the cusp of being possible, thanks to AI-assisted formal verification. So we should be frontrunners in doing this.

* Available chain consensus. Ethereum is, and with lean consensus will cotninue to be, the ONLY chain that has both (i) traditional-BFT style properties that it's safe under asynchrony up to a high level of fault tolerance, and (ii) the bitcoin PoW-style property that under synchrony it's safe up to 49% attackers. As far as I can tell, literally no other chain has this or is planning for it; bitcoin goes for (ii) only and most other chains go for (i) only. Some will remember I fought hard for this, Unreasonably insisting that it is not OK for ethereum to rely on social consensus and hard forks to rescue ethereum from 34% of nodes going offline. It's OK for chains like hyperledger, bnb, solana, tempo, etc. It's not OK for bitcoin or ethereum or eg. zcash.

* Intermediary minimization. The fact that smart contract wallets, protocols like railgun, etc have to send transactions through intermediaries to get included onchain is honestly embarrassing, and it's a constant point of fragility. Hence the work on FOCIL and EIP-8141 (and 7701 and years of work before) to make transaction sending intermediary-minimized with public mempool and strong inclusion properties, in a truly general-purpose way, that covers not just eg. secp256r1, but also privacy protocols and much more. Kohaku is pushing intermediary minimization at the user layer, pulling Ethereum away from the dystopian status quo world where our wallets don't even verify the chain, send our private data out to a dozen third-party servers, and toward a brighter CROPS future.

Some of these goals are Unreasonable - maybe Ethereum would be "fine" getting only 50% of the way - what if we depend on intermediaries, but make it easy to switch? But going 50% of the way would not make Ethereum Deeply Impressive in the CROPS way. So we push for 100%.

Fortunately all these goals are compatible with high TPS, this is a major focus of research (esp. on scaling the state). Well-designed L2s can also help, especially L2s optimized for specific applications (eg. high-volume trading, privacy...). These goals are even compatible with significantly lower slot times, thanks to Raul's work on erasure-coded P2P, and many other optimizations.

The most high-value "product" of the ethereum blockchain, financially speaking, is ETH the asset. Ethereum secures $250 billion of ETH. The types of properties of Ethereum that I mentioned above are very good for ETH the asset. Nearly 90% of my net worth is in ETH, and most of the remainder is ~$40m of onchain fiat of which every dollar has already been allocated for some open-source biotech or software or hardware initiative. That said, there are aspects of supporting ETH the asset - *necessary* aspects even - that are outside the scope of the EF. This is where we need other heroes (some of whom hold more ETH than the EF does) to step in and help. EF has been recently thinking more about how it will relate to other such organizations, and give them needed initial support.

EF will be a smaller ship than in previous years, a more opinionated one - in some cases more opinionated in ways that might be difficult to comprehend - but a longer-lasting one, and one suited to making sure that ethereum brings something meaningful to the world. We are grateful to all those inside and outside the EF who are helping to make this happen.

[Toni Wahrstätter ⟠ @nero_eth]

Ethereum is about to fundamentally change how blocks are executed. With the upcoming Glamsterdam hardfork, it's shipping EIP-7928: Block-level Access Lists, a proposal that brings parallelization to the EVM.

Here's a short explainer of what it is, how it works, and why it's a big deal for scaling.

Let's start from the top. Alongside EIP-7732 (ePBS), EIP-7928 is the execution-layer (EL) headliner for Glamsterdam. Like ePBS, the main focus has been scaling Ethereum, though both proposals come with a bunch of other, equally important properties on the side e.g. removing trust requirements from the PBS pipeline or improving sync.

EIP-7928 adds a Block Access List (BAL) to every Ethereum block. A BAL is a list of accounts and storage slots that the block touches, but that's not all: it also contains post-transaction state diffs (this part is critical!).

Post-transaction state diffs tell you what the state looks like after each transaction. Quick example: user A swaps 1 ETH for DAI on DEX B. The BAL tells you that user A's ETH balance decreased by 1 ETH + tx fees and their nonce went up by 1; that DEX B's ETH balance went up by 1 ETH; and that inside the DAI contract, user A's DAI balance increased while DEX B's decreased.

In other words, all of that info becomes statically available, something that previously required tracing the transaction.

Client software (Geth, Nethermind, Besu, Erigon, Reth, Ethrex, Nimbus) can use this to do a few very powerful things:

1. Parallelize transaction execution. Knowing the post-state of each tx resolves the dependencies between them. No transaction has to wait on the previous one anymore, so execution can be perfectly parallelized. Instead of large parts of block validation sitting idle waiting on sequential execution, clients can finally make much better use of modern hardware.

2. Batch prefetch. One of the most cumbersome jobs for a node has been fetching the state needed for execution from disk. Because state locations (e.g. the exact storage slot in the DAI contract where user A's balance lives) are only discovered along the way, while executing, state-fetching has been a real drag on scaling: it blocks execution, takes time, and eventually slows everything down. With BALs, everything a node needs for execution is known upfront and can be loaded into cache in one go, in parallel. This speeds things up even further.

3. Parallelize post-state root calculation. Another expensive task is walking the updated state tree to compute the post-state root, which is needed so that everyone agrees on what's on disk after executing the block. With the post-tx state already in the BAL, nodes can do this in parallel while executing. A heavy task that used to wait until all transactions had finished can now run alongside prefetching and execution.

4. Snap sync (v2). An often overlooked, less sexy aspect of blockchains is syncing. Nodes need to catch up with the chain, and they need to catch up faster than the chain progresses. Today, most nodes do snap sync: downloading blocks, headers, and state in parallel while chasing the tip, and then "healing" the database once they're close to the head. Healing means asking peers for trie nodes, receiving them, validating them, and updating the local DB. It's iterative, networking-heavy, can take a while, and especially higher throughput pushes that phase to its limits. BALs help here too: with snap v2, nodes can catch up to the tip and skip the healing phase entirely. Syncing at higher throughput becomes more robust and reliable.

So, to summarize, a BAL contains two things:
-> The state locations the block accesses
-> The state changes after each tx (incl. the new values)
We're already seeing big performance gains today: on 6-core machines, EL clients validate blocks up to 5x faster, making block gas limits of 300M a very realistic outcome. ePBS will add to that by decoupling the block from the payload, giving validators 2-4x more time for execution.

To not overshoot (security stays priority #1), the fork will likely ship with a 200M gas limit, but we shouldn't be stuck there for long before pushing to 300M and beyond. That's a 10x in scaling since we started taking the topic seriously, without touching hardware requirements.

None of this would have happened without people going all-in, heads down, shipping: so many hours spent in calls debating the right design, so many iterations refining the specs, and tons of test cases written (and still being worked on). The road from whiteboard to production-ready code has been a journey, and we're not at the finish line yet, but from what I can tell, things look super bullish for Ethereum.

Glamsterdam will be a fork that shows what's possible when a distributed, decentralized community works on a shared goal, laser-focused on providing enough block space to onboard the next wave of users.

[Stefanie Ungar @ungar_stefanie]

Been getting a lot of questions about where to find the ESPN documentary on my dad. My mom and l are so grateful to have been involved in it, and we're incredibly proud of it. The documentary won 4 Emmys, including Best Documentary of the year and Best Writing. The link is below.

One of a Kind: The Rise and Fall of Stu Ungar (Documentary Film) https://t.co/1qESxWFgNm via @YouTube

[Devcon 8 | Mumbai, India 🇮🇳 @EFDevcon]

https://t.co/aXOxcVrSMw

[GEE-yohm LAMB-bear @guil_lambert]

Introducing DeFiPunk'd: an @l2beat-inspired registry for the whole DeFi stack.

Human curation doesn't scale, so DeFiPunk’d crowdsources reports from users (you!) running standard LLM prompts, with humans making the final call.

Already tracking 8105 protocols. Details below!

[Sam MacPherson @hexonaut]

https://t.co/JrHuxON7YR

[Dapp-Learning @Dapp_Learning]

DappLearning 分享会预告：
分享者：@wong_ssh
标题：Uniswap V4 新机制实现的代码阅读
主要内容：
介绍 Uniswap V4 内的 Singleton / Flash Accounting / Hook 相关部分的代码

会议时间：8:00pm, Apr 9th
会议语言：中文
会议链接：https://t.co/YGeM1Oru92

分享材料：https://t.co/WVNIXGttE4

[Frank 丨冰糖橙聚合 @0x0Frank]

如果你想了解交易的本质与人性的弱点，请看《股票大作手回忆录》

如果你想达到最佳的执行状态并建立概率思维，请看《交易心理分析》

如果你想掌握如何建立一套完整的交易系统与严密的仓位管理，请看《海龟交易法则》

如果你想把交易灵感转化为自动执行的代码与客观模型，请看《量化交易：如何建立自己的算法交易事业》

如果你想建立资金管理、风险控制与市场哲学的立体框架，请看《以交易为生》

如果你想为长期的核心底仓寻找稳健的锚点与安全边际，请看《聪明的投资者》

如果你想抛弃对行情的预测，单纯依靠价格行为去捕捉大级别利润，请看《趋势跟踪》

如果你想探索宏观预期与价格之间相互强化的互动关系，请看《金融炼金术》

如果你想学习技术分析的基础与图表背后的多空情绪博弈，请看《日本蜡烛图技术》

如果你想学会敬畏市场并应对不可预知的极端风险，请看《黑天鹅》
——Frank荐书频道

[Dapp-Learning @Dapp_Learning]

Defi伯克利公开课——defi安全入门

本节课将带你进入 DeFi 体系中的“系统安全层”——跨层攻击、MEV 驱动与防御机制设计。跟随 Arthur Gervais 教授的研究框架，从网络、共识、合约到应用多个层级，建立一套贯穿通信、执行与经济激励的整体性安全认知。

课程以分层结构为基础，呈现风险在不同层级之间的传导与放大机制，并以 MEV 作为统一变量，将交易排序、套利行为与共识激励整合为连续运转的收益系统。同时，通过机制设计与形式化方法，将安全能力嵌入协议结构之中，形成跨层协同的稳定机制。

在这一框架下，DeFi 安全由局部问题收敛为系统性命题，其本质是在开放与对抗环境中，通过结构与激励的平衡，实现长期稳定运行。

https://t.co/QwyyH0hP51

[Julian @_julianma]

https://t.co/7WZDKbB4Iz

[RYAN SΞAN ADAMS - rsa.eth 🦄 @RyanSAdams]

Um...did the EF just roll out a way to drop Ethereum finality from 13 mins to...13 second??

Bullish if true.

Fast confirmation rule.

https://t.co/kY9cN8OSOz

[Dapp-Learning @Dapp_Learning]

伯克利Defi公开课最新一课——去中心化身份入门

本节课将带你进入 DeFi 体系中被长期忽视却至关重要的“身份基础层”——去中心化身份（Decentralized Identity）。跟随 Andrew Miller 教授一起理解：当金融系统不再依赖银行账户、政府证件或中心化平台来确认“你是谁”，而是用公钥、密码学证明与信任网络来表达身份，链上世界应该如何建立信任？

你将不再把“身份”理解为传统意义上的 KYC 或实名验证，而是能够从机制层面看清：传统互联网如何通过 OAuth、账户体系与中心化数据库来管理身份；DeFi 又如何借助数字签名、零知识证明、预言机与匿名凭证，把身份验证从机构流程转化为可验证的密码学证明；信任结构如何从中心化机构迁移到密码学协议的范式转变。

课程链接：
https://t.co/0UsFhx2FVF

[AI on Base @AIonBase_]

ERC-8183 Explained

@virtuals_io x @ethereumfndn's dAI team just dropped the first native commerce standard for AI agents.

agents can move tokens today. but moving tokens is not commerce.

there's no proof work was done. no way to hold funds until delivery. no recourse if the provider disappears.

ERC-8183 makes it commerce.

the core primitive: a Job.

three roles:
- Client (hires)
- Provider (does the work)
- Evaluator (verifies the work was actually done)

Open → Funded �� Submitted → Completed / Rejected / Expired

payment sits in escrow.

work done = provider paid.
rejected = client refunded.
no action before deadline = auto-refund.

the Evaluator is just an address.

an AI agent, a ZK verifier, a multisig.
the contract doesn't care.

a $0.10 image gen job and a $100k fund management engagement run through the exact same contract.

for everything beyond the base flow, there are hooks.

milestone payments, reputation gating, bidding, ZK privacy. all hooks.

any wallet can be a Provider.

every completed job feeds ERC-8004, the agent identity standard.

completed job = onchain reputation
submission = verifiable history
attestation = portable trust

Discovery (8004) → Commerce (8183) → Reputation (8004) → loop

good work = reputation = more clients = more jobs.

Virtuals team is building the most important standard for agentic commerce stack in the open, co-developed with ethereum's dAI team.

spec: https://t.co/OfpPWJYIaY

[YQ @yq_acc]

https://t.co/tOv0X5p1H9

[Justin Drake @drakefjustin]

Introducing strawmap, a strawman roadmap by EF Protocol.

Believe in something. Believe in an Ethereum strawmap.

Who is this for?

The document, available at strawmap[.]org, is intended for advanced readers. It is a dense and technical resource primarily for researchers, developers, and participants in Ethereum governance. Visit ethereum[.]org/roadmap for more introductory material. Accessible explainers unpacking the strawmap will follow soon™.

What is the strawmap?

The strawmap is an invitation to view L1 protocol upgrades through a holistic lens. By placing proposals on a single visual it provides a unified perspective on Ethereum L1 ambitions. The time horizon spans years, extending beyond the immediate focus of All Core Devs (ACD) and forkcast[.]org which typically cover only the next couple of forks.

What are some of the highlights?

The strawmap features five simple north stars, presented as black boxes on the right:

→ fast L1: fast UX, via short slots and finality in seconds
→ gigagas L1: 1 gigagas/sec (10K TPS), via zkEVMs and real-time proving
→ teragas L2: 1 gigabyte/sec (10M TPS), via data availability sampling
→ post quantum L1: durable cryptography, via hash-based schemes
→ private L1: first-class privacy, via shielded ETH transfers

What is the origin story?

The strawman roadmap originated as a discussion starter at an EF workshop in Jan 2026, partly motivated by a desire to integrate lean Ethereum with shorter-term initiatives. Upgrade dependencies and fork constraints became particularly effective at surfacing valuable discussion topics. The strawman is now shared publicly in a spirit of proactive transparency and accelerationism.

Why the "strawmap" name?

"Strawmap" is a portmanteau of "strawman" and "roadmap". The strawman qualifier is deliberate for two reasons:

1. It acknowledges the limits of drafting a roadmap in a highly decentralized ecosystem. An "official" roadmap reflecting all Ethereum stakeholders is effectively impossible. Rough consensus is fundamentally an emergent, continuous, and inherent uncertain process.
2. It underscores the document's status as a work-in-progress. Although it originated within the EF Protocol cluster, there are competing views held among its 100 members, not to mention a rich diversity of non-EFer views.

The strawmap is not a prediction. It is an accelerationist coordination tool, sketching one reasonably coherent path among millions of possible outcomes.

What is the strawmap time frame?

The strawmap focuses on forks extending through the end of the decade. It outlines seven forks by 2029 based on a rough cadence of one fork every six months. While grounded in current expectations, these timelines should be treated with healthy skepticism. The current draft assumes human-first development. AI-driven development and formal verification could significantly compress schedules.

What do the letters on top represent?

The strawmap is organized as a timeline, with forks progressing from left to right. Consensus layer forks follow a star-based naming scheme with incrementing first letters: Altair, Bellatrix, Capella, Deneb, Electra, Fulu, etc. Upcoming forks such as Glamsterdam and Hegotá have finalized names. Other forks, like I* and J*, have placeholder names (with I* pronounced "I star").

What do the colors and arrows represent?

Upgrades are grouped into three color-coded horizontal layers: consensus (CL), data (DL), execution (EL). Dark boxes denote headliners (see below), grey boxes indicate offchain upgrades, and black boxes represent north stars. An explanatory legend appears at the bottom.

Within each layer, upgrades are further organized by theme and sub-theme. Arrows signal hard technical dependencies or natural upgrade progressions. Underlined text in boxes links to relevant EIPs and write-ups.

What are headliners?

Headliners are particularly prominent and ambitious upgrades. To maintain a fast fork cadence, the modern ACD process limits itself to one consensus and one execution headliner per fork. For example, in Glamsterdam, these headliners are ePBS and BALs, respectively.

(L* is an exceptional fork, displaying two headliners tied to the bigger lean consensus fork. Lean consensus landing in L* would be a fateful coincidence.)

Will the strawmap evolve?

Yes, the strawmap is a living and malleable document. It will evolve alongside community feedback, R&D advancements, and governance. Expect at least quarterly updates, with the latest revision date noted on the document.

Can I share feedback?

Yes, feedback is actively encouraged. The EF Protocol strawmap is maintained by the EF Architecture team: @adietrichs, @barnabemonnot, @fradamt, @drakefjustin. Each has open DMs and can be reached at first.name@ethereum[.]org. General inquiries can be sent to strawmap@ethereum[.]org.

[宝玉 @dotey]

斯坦福大学去年秋季开了一门新课 CS146S，叫"现代软件开发者"，由知名风投 a16z 的合伙人 Martin Casado 主讲，核心主题就一个：AI 时代怎么写代码。

课程的基本观点是，软件开发已经从"从零手写代码"变成了"规划→AI生成→修改→循环"的新工作流。课上会教学生怎么用 LLM 高效提示、搭建 AI 编程代理、用 Claude Code 等工具做��发，还涉及 AI 代码审查、安全漏洞检测、自动化测试等实战环节。

阵容很豪华，每周都有业界嘉宾来讲课——Cognition（Devin 背后的公司）的研究负责人、Claude Code 的创造者 Boris Cherney、终端工具 Warp 的 CEO、代码安全公司 Semgrep 的 CEO、Vercel 的 AI 研究负责人等等，基本把 AI 编程工具链上的关键���家请了个遍。

课程为期一个学期，3 学分，要求有编程基础，每周大概 10-12 小时的投入。最终项目是做一个展示现代开发实践的作品。

https://t.co/6ecEpIQ7A2

[Dapp-Learning @Dapp_Learning]

精彩分享来了，关注去中心化预测市场的同学��要错过。

标题：Polymarket 全解析：深度拆解 “Yes/No” 背后的运作机制(Polymarket Deconstructed: What Happens Behind the Scenes of Every "Yes/No" Click?)
主要内容：
- Yes/No tokens Trading
- Binary/Negrisk/Sports market creating/resolving

会议时间：8:00pm, FEB 25th
会议语言：中文
会议链接：https://t.co/iYftLyUxnE
腾讯会议：585-741-893
分享材料：https://t.co/QuOojCCrqZ

[Dapp-Learning @Dapp_Learning]

@DeriveXYZ_CN @SeanNotShorn 哈哈，可以来我们社区讲讲吗

[Dapp-Learning @Dapp_Learning]

🚀 New Sharing Session!

Deep dive into the Cypherpunk tech stack with @hackyguru from @logos_network.

We’re moving beyond standard EVM pitfalls to explore a decentralized future combining.

📅 Feb 11th, 8:00 PM (UTC+8)
🎙️ Language: English
📍 Join here: https://t.co/QOVAFYlaWi