1. 基础信息
- 项目名称：my first ZK-vote
- 负责人：@Elon
- 关联主线：
2. 项目描述
What
整个教学网页分为五个部分：
- 介绍区块链交易 ：介绍一个完整的区块链交易的如何发出并打包上链的，交易中包含什么数据和内容，如何在区块链上查看自己的交易信息；
- 介绍ZK-SNARKs的概念，并完整的一次依赖ZKSNAKRs的交易的过程；
- 引导用户体验一次完整L2链投票；
- 引导用户体验一次通过服务端生成证明提交到链上合约验证的过程；
- 对比两者投票过程的不同，gas费用和隐私性的不同；
Why
这个教学网页可以让用户学习到什么是区块链交易，什么是链上投票，什么是ZK，和ZK SNARKs，为后续组织投票上链奠定基础
How
整体采用 React + TypeScript 构建前端，Solidity 编写智能合约，Node.js 实现后端证明生成，结合 Circom/snarkjs 完成零知识证明相关功能
3. 资金申请
- 联系方式：Wachat : CYL-Elon
- 申请金额：400 USDT
- 资金用途：本次申请为一次性激励，用于覆盖产品界面设计、前端开发实现、配置等核心环节的工作成本，保障项目按时落地。
4. Milestone 计划
（Milestone 审核通过后执行）
5. 项目需求（可选）
暂无
1 Like
我正在做dapp的开发，如果有需要的话可以联系我帮忙制作
新的项目描述：
1. 基础信息
- 项目名称：My First ZK-Vote
- 负责人：@Elon
- 关联主线：
2. 项目描述
What 什么
整个教学网页分为四个部分：
一、什么是区块链交易
- 介绍什么是区块链交易（图文描述，需要UI设计）
- 区块链交易的定义
- 区块链交易的特点
- 交易与区块的关系
- 交易的生命周期
- 交易的组成部分（卡片展示）
- 不同共识下的交易确认差异
- PoW（如比特币）
- PoS（如以太坊合并后）
- Rollup / L2（如 Optimism、zkSync）
二、什么是ZK（引用官方的介绍框架）
1、what is ZK ZK是多少
2、ZK的性质
3、ZK的分类
4、ZK的工作原理（加密机制，算法介绍，主要介绍ZKSNARKS的Groth16方案）
5、区块链上的应用（介绍一些优质项目，引申出投票）
- 隐私交易 / 隐匿交易金额、交易双方：例如 Zcash 使用 zk-SNARK 来隐藏转账金额与地址信息。 Nervos Network+3Nervos Network+3Chainlink+3隐私交易 / 隐匿交易金额、交易双方：例如 Zcash 使用 zk-SNARK 来隐藏转账金额与地址信息。 Nervos Network 3Nervos Network 3Chainlink 3
- 链下计算 + 链上验证（可扩展性）：如 zk-Rollup 批量交易先在链下聚合计算，再生成一个 ZKP 在主链上验证。
- 匿名投票 / 身份验证：用户可以证明自己有投票资格 / 身份特征，而不暴露具体身份。
- 混合公私链 / 跨链验证：可用于验证跨链操作或混合链上链下操作正确性而不暴露细节。
- 机密合约 / 隐私合约：使合约在执行过程中，部分数据保持私密
三、一次sepolia链上投票
1、页面展示一个投票选项，选择选项投票后提交到sepolia的合约中记录投票数据
2、页面返回交易TX，用户在区块链浏览器可查看投票交易数据
四、一次ZK-SNARKs投票
1、页面端存入数字电路（可用semaphore项目的电路文件），生成信用设置
2、用户选择选项，生成证明，提交sepolia链上（也可以是ZKSync测试链）
3、链上合约验证并统计数据
4、引导用户查看交易数据
Why 为什么
通过图文与交互动画，帮助用户从“理解区块链交易” → “体验普通投票交易” → “理解并体验 ZK 投票”的全过程，可以让用户学习到什么是区块链交易，什么是链上投票，什么是ZK，和ZK SNARKs，为后续组织投票上链奠定基础
How 如何
| 步骤 |
功能 |
前端技术栈 |
说明 |
 教学讲解 |
交易流程讲解（非 3D、滑动交互） |
React + Framer Motion + D3.js + TailwindCSSReact Framer Motion D3.js |
通过滑动（scroll-snap 或 Swiper.js）展示交易从创建到上链的过程。 |
 钱包连接 |
用户连接 MetaMask |
wagmi + viem wagmi viem |
引导用户连接钱包，检测网络是否为 Sepolia。 |
 模拟投票 |
在 Sepolia 模拟提交投票 |
ethers.js + wagmi ethers.js wagmi |
用户点击投票按钮，执行一次链上交易（Sepolia）。 |
 ZK 证明 |
客户端生成 ZK 证明 |
snarkjs + circomlibjs + WebAssembly (WASM)snarkjs circomlibjs WebAssembly （WASM） |
用户本地生成 proof.json 与 publicSignals.json，不上传隐私数据。 |
 证明上传 |
提交 proof 到 zkSync 验证合约 |
zkSync SDK + ethers.js + 自写合约zkSync SDK ethers.js 自写合约 |
调用 zkSync 上部署的验证器合约进行验证。 |
 结果展示 |
展示投票结果或验证状态 |
React + Recharts / Chart.jsReact Recharts / Chart.js |
可视化展示每个投票项的结果或用户的验证通过情况。 |
3. 资金申请
- 联系方式：Wachat : CYL-Elon
- 申请金额：暂定（工作量还需讨论）
- 资金用途：本次申请为一次性激励，用于覆盖产品界面设计、前端开发实现、配置等核心环节的工作成本，保障项目按时落地。
4. Milestone 计划
（Milestone 审核通过后执行）
| 时长 |
交付结果 |
| 30days 30天 |
初步demo |
| 15days 15天 |
测试 |
5. 项目需求（可选）
wachi
6
建议不要用 ethers.js 了，直接用 viem + wagmi 就行（因为 wagmi 也是 viem 的团队开发的，底层依赖了 viem），两个功能一样的库（etherjs、viem）在一个代码库里，容易造成混乱。而且 viem 是类型安全的，只要传入 abi 能自动解析成正确的类型，在 buildtime 就能找出错误的地方，之后 vibe coding 也不容易错。
wachi
9
感觉最核心的部分还是动画交互的部分。
@CYL12345 你该把研究报告也放过来，加强你做这一部分的权威性。
1. 基础信息
- 项目名称：My First ZK-Vote
- 负责人：@Elon
- 关联主线：
2. 项目描述
What
整个教学网页分为四个部分：
一、什么是区块链交易
- 介绍什么是区块链交易（图文描述，需要UI设计）
- 区块链交易的定义
- 区块链交易的特点
- 交易与区块的关系
- 交易的生命周期
- 交易的组成部分（卡片展示）
- 不同共识下的交易确认差异
- PoW（如比特币）
- PoS（如以太坊合并后）
- Rollup / L2（如 Optimism、zkSync）
二、什么是ZK（引用官方的介绍框架）
1、what is ZK
2、ZK的性质
3、ZK的分类
4、ZK的工作原理（加密机制，算法介绍，主要介绍ZKSNARKS的Groth16方案）
5、区块链上的应用（介绍一些优质项目，引申出投票）
- 隐私交易 / 隐匿交易金额、交易双方：例如 Zcash 使用 zk-SNARK 来隐藏转账金额与地址信息。 Nervos Network+3Nervos Network+3Chainlink+3
- 链下计算 + 链上验证（可扩展性）：如 zk-Rollup 批量交易先在链下聚合计算，再生成一个 ZKP 在主链上验证。
- 匿名投票 / 身份验证：用户可以证明自己有投票资格 / 身份特征，而不暴露具体身份。
- 混合公私链 / 跨链验证：可用于验证跨链操作或混合链上链下操作正确性而不暴露细节。
- 机密合约 / 隐私合约：使合约在执行过程中，部分数据保持私密
三、一次sepolia链上投票
1、页面展示一个投票选项，选择选项投票后提交到sepolia的合约中记录投票数据
2、页面返回交易TX，用户在区块链浏览器可查看投票交易数据
四、一次ZK-SNARKs投票
1、页面端存入数字电路（可用semaphore项目的电路文件），生成信用设置
2、用户选择选项，生成证明，提交sepolia链上（也可以是ZKSync测试链）
3、链上合约验证并统计数据
4、引导用户查看交易数据
Why
通过图文与交互动画，帮助用户从“理解区块链交易” → “体验普通投票交易” → “理解并体验 ZK 投票”的全过程，可以让用户学习到什么是区块链交易，什么是链上投票，什么是ZK，和ZK SNARKs，以后ZK技术会是隐私审计和个人ID的重要技术，让大家提前了解何为ZK，为后续组织投票上链奠定基础
How
| 步骤 |
功能 |
前端技术栈 |
说明 |
| 教学讲解 |
交易流程讲解（非 3D、滑动交互） |
React + Framer Motion + D3.js + TailwindCSS |
通过滑动（scroll-snap 或 Swiper.js）展示交易从创建到上链的过程。 |
| 钱包连接 |
用户连接 MetaMask |
wagmi + viem |
引导用户连接钱包，检测网络是否为 Sepolia。 |
| 模拟投票 |
在 Sepolia 模拟提交投票（真实上链） |
viem |
用户点击投票按钮，执行一次链上交易（Sepolia）。 |
| ZK 证明 |
客户端生成 ZK 证明,使用groth16 |
snarkjs + circomlibjs + WebAssembly (WASM) |
用户本地生成 proof.json 与 publicSignals.json，不上传隐私数据。 |
| 证明上传 |
提交 proof 到 zkSync 验证合约 |
zkSync SDK + ethers.js + 自写合约 |
调用 Sepolia 上部署的验证器合约进行验证。 |
| 结果展示 |
展示投票结果或验证状态 |
React + Recharts / Chart.js |
可视化展示每个投票项的结果或用户的验证通过情况。 |
3. 资金申请
- 联系方式：Wachat : CYL-Elon
- 申请金额：暂定
- 资金用途：本次申请为一次性激励，用于覆盖产品界面设计、前端开发实现、配置等核心环节的工作成本，保障项目按时落地。
4. Milestone 计划
（Milestone 审核通过后执行）
| 时长 |
交付结果 |
| 30days 90工时 |
整套页面+数字电路+合约验证成品 |
|
|
5. 项目需求（可选）
**6.当前小组成员：Elon 、Draken 、苏
研究报告：Notion
1 Like
wachi
11
有个idea：不如把这个APP扩展成一期残酷共学？
课程设计：
- 周期为一个月
- 每周一节课
- 中间穿插两次workshop
- 主流zk应用的操作课
- 最简单zk应用的开发课。
- 准备一到两次space，邀请从业者解读隐私最新进展（Brevis、TEE、ZK等）
- 最后用本应用投票，表决课程质量
- （可选）组织一次CasualHackathon，进一步激发开发者的想象力
为了支持以上项目，需要：
- 增加申请资金，不超过1ku。相对于现在的scope，额外部分用于支持课程设计、workshop设计、运营同学bounty等等。
- 寻求 LXDAO 及 ETHPanda 宣发支持
- 寻求BD支持
各方利益：
- 项目本身：大家能学习得更加充分，切入方式也更加丰富（不只10分钟玩一下网站，更能知道其原理，并能在经过一个月的充分思考之后，真正用项目投一次有意义的票）
- 参与工作的同学们：zk这个热门话题相关的实战工作经验。
- LXDAO：在 ERC8004 共学之外，及时把握潜在热点，凸显技术驱动公共物品的理念。同时借此机会与最新的zk从业者建立联系。
相信有之前实习计划的铺垫和人才储备，以及各种BuildPath suite的支持，这个事情没有想象的困难。
1 Like
我也有这个想法，ZK残酷共学是十分有前景的一次共学，包括ZKID，和ZK和8004的结合都很有许多应用场景，现在很多Defi也在强调隐私审计，不过ZK是有一定入门门槛的技术，设计密码学和一些算法，这样的课程设计需要比较详细的规划同时也需要很多资源，我是想先做一个这样的入门网页，最后这个网页也会是ZK残酷共学的入门的一环，ZK这个学习一定会是长期的，后续还可以细分应用场景
Alice
13
挺有可行性的一个方案。特别还是前面还有教学讲解这个（这个倒是日常开发容易忽略问题）。
仔细看了一下，还是有一些难点问题可能需要注意：
- Groth16 需要 per-circuit trusted setup（proving key / verification key）。若使用现成的 Semaphore 电路，需要确保 zkey 的来源可信。
- 在 EVM 上验证 Groth16 证明需要 pairing 运算（BN254 等），合约很大、gas 消耗高。大量单次验证会非常昂贵。（当然只是测试链演示无所谓，但是都需要考虑）。
最后还有一个问题，回到原点应用场景与成本问题了。
证明上传 提交 proof 到 zkSync 验证合约 zkSync SDK + ethers.js + 自写合约 调用 Sepolia 上部署的验证器合约进行验证。
这儿利用第三方服务呢？还是自建中心化后端（Server-Assist）。如果整个项目不是客户端直接证明上链的化。其实都可以没必要上ZK了。有个后端弄简单判断一下。就完了。（当然这是场景与成本问题）。
上ZK的链上确认投票场景，其实还应该有一些配套才是。比如某种意义只能是比较严肃的正式提案级投票才会用的。不然真的多人投票烧的GAS都不少。
如果类似临时事务一些快速表态性投票场景。就没必要这么做。
可搞简单点：用户先提交资格证明（链上地址证明）给在 Docker 封闭容器 + TEE（如 SGX，整个容器持有hash比对验证有效性与安全性、匿名性） 中运行的资格颁发器（Issuer）；Issuer 在 TEE 内执行盲签协议（Chaum 风格或 BLS-based blind sig），只向合格用户返回不可追溯的一次性匿名 token，且不在外部持久化对应关系或敏感日志。持 token 的用户通过 relayer 提交 vote + token，投票接收端在同一 TEE 或链下受保护环境中验证 token 有效性并检查其是否已被使用（防双投），合格票计入本地 tally；投票期结束后，TEE 对聚合结果签名并提供远程 attestation（可供第三方验证），然后将汇总 tally 一次性上链——因此前端用户无需支付 gas（0gas 体验），链上仅记录不可反推的汇总结果。优点是极低的链上成本与在合理信任下的高匿名性。估计这个都复杂了。也许本来就是封闭可信环境，签名，验证签名，+1+1，反馈简单事情。
不过这么就挺不web3了，也没什么ZK事了。
确实，从成本角度来看，TEE + 盲签 + Relayer 的组合要明显优于纯 ZK 方案，但这种架构的中心化程度太高，不符合我们想要传达的 Web3 精神。
我们这次的目标是做一个 ZK 教学项目，希望让参与者*亲身体验到真正“链上抗审查、可验证”的 ZK 投票流程**。如果仅依赖可信服务器或 TEE，就失去了 ZK 的本质“去信任”特性，也就不够酷了。
至于 Gas 成本，我们确实不需要太担心——除了可以直接使用测试链（几乎零成本）外，我也考虑过将证明验证的计算压力放到更经济的环境中，比如：
- 在 zk-rollup 的验证网络*或
- 专门的验证层（如 zkVerify）
上执行 ZK proof 的验证，只把最终的聚合证明或状态承诺（commitment）回传到 L1 或目标链。这样既能保留全链上可验证性，又能显著降低验证成本。
当然，考虑到这是一个教学示例，选择对应的 L2 测试链来部署会更合理零成本、全链上、体验完整、去信任程度高，同时更好地展示 ZK 的实际应用价值
1 Like
I am a builder card holder, I second this proposal.
I am a builder card holder, I second this proposal.
I am a builder card holder, I second this proposal.
Alice
18
加油，看好你们哦!
忘记了，这玩意用cairo写，比solidity写简单得多。