Solidity 经典合约示例：投票、拍卖与支付通道详解

投票合约：透明委托投票系统

核心要点

• 合约关键字：投票、Solidity、委托、主席
• 功能概要：支持独立投票或委托投票，最终自动统计并公布赢得最多票数的提案

运行机制

1. 部署阶段：主席创建合约并设置全部提案名称
2. 授权阶段：主席逐一把投票权分配给可信地址

3. 投票阶段：

   • 持权者可自己投票
   • 亦可把投票权委托给另一名可信地址
4. 统计阶段：winningProposal() 自动返回最高票数提案

FAQ

Q1：如何防止一权多投？
A：每个 Voter 标志位 voted 一旦置 true，后续相同地址再投票会被拒绝。

Q2：支持并列平局优化吗？
A：现版本不处理平局；你可以扩展计票逻辑，记录并列的提案索引后由主席二次裁决。

Q3：委员会主席后期还能增加投票人吗？
A：当前实现只能初始化一次。建议再写 addVoter() 并加上委员会多重签名，防止单点扩权。

👉 立即上手运行示例：一键直达在线 IDE，零环境配置玩转投票合约。
动手试跑投票合约

盲拍合约：从公开到私密竞价

简单公开拍卖流程

• 部署：beneficiary 设定拍卖结束时间
• 竞价：bid() 接受高于当前最高价的以太
• 结束：到达结束时间后任何人可调用 auctionEnd() 触发结算

盲拍升级亮点

• 分阶段：投标期 → 揭示期 → 揭示结束
• 加密出价：使用 keccak256(value, fake, secret) 隐藏真实价格
• 押金保护：未中标或错误揭示自动退款

FAQ

Q1：在盲拍中揭露阶段可以追加竞价吗？
A：不可以，reveal() 期间只能匹配之前已投的哈希，无法再新增。

Q2：如何保证揭示期不被无限延长？
A：硬编码 revealEnd 并在 onlyBefore / onlyAfter 修饰器强制执行区块时间。

Q3：盲拍是否会消耗更多 gas？
A：确实高于公开拍卖；建议批量合并 bid() 到后端脚本，减少链上交易数。

安全远程购买：双向托管设计

场景再现

• 痛点：交易双方互不信任，物流真实性无凭据

• 机制：双方均额外交付 100% 押金，通过状态机演进

  1. Created：买方锁定 2×商品价值的以太
  2. Locked：卖方发货
  3. Release：买方确认收货并触发退款
  4. Inactive：合约结束，卖家拿回 3×原始金额，买家拿回多余押金

FAQ

Q1：真的能起到约束作用吗？
A：押金等于两倍商品价值，双方均有强烈经济动机按流程完成交易，否则资金永远锁定。

Q2：若物流延迟导致超时怎么办？
A：合约本身无延时逻辑，可在 Release 状态前由双方链下协商延长；或增加 extendLock() 函数。

微支付通道：高频零费转账利器

链下签名支付三步

1. 开通道：Alice 把资金存入 SimplePaymentChannel 并指定 Bob 为收款人及到期时间
2. 发支付：Alice 离线签署累计金额，Bob 持有最新签名
3. 关通道：Bob 可随时链上调用 close() 提现，Alice 未用完资金自动退回

关键保护

• 防重放：每条签名包含合约地址 & nonce
• 超时退款：若 Bob 不主动关闭，Alice 到期即可 claimTimeout()
• 无法窜改：只有接收者可调用 close()，确保 Bob 使用最新金额

FAQ

Q1：为什么不要 nonce 于最终签名？
A：单笔通道只兑现一次；累计金额天然防止重排，用地址即足够。

Q2：通道可否双向支付？
A：当然可以！双向只需让双方都可签署增减余额，复杂点在于对账与结算。

👉 想要 0 手续费转发你的下一份工资？点这里查看完整支付通道代码详解。
无 gas 转账通道实战

模块化合约：库复用与安全保障

设计思路

• 把核心逻辑拆入独立库，如 Balances.move() 确保总量守恒
• 合约仅做流程调度，减少复杂校验

可拓展实践

• 新生态代币可直接 using Balances for*; 无缝复用转账安全
• 审计时只需验证库是否溢出/下溢，其他逻辑一目了然

总结与最佳实践

1. 投票合约 强调过程透明和最终自动结算
2. 拍卖合约 展示从简到繁的安全竞价模式
3. 托管合约 体现双向经济激励解决信任缺失
4. 支付通道 利用离线签名实现高频零费场景
5. 模块化 将可验证单元抽离，降低 Bug 面

无论你准备做链上治理还是去中心化商业，上述范例都能作为坚实起点；欢迎 fork 后自行定制并反馈改进。