news 2026/4/24 20:30:30

婚礼礼金记账程序,礼金记录链式存储,公开透明避免账目不清,亲友误会。

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
婚礼礼金记账程序,礼金记录链式存储,公开透明避免账目不清,亲友误会。

解决一个极具中国特色、且极易引发家庭矛盾的痛点——婚礼礼金(份子钱)的糊涂账。

作为开发者,我们不仅要写代码,更要懂得人情世故。如何利用区块链技术,让“谈钱不伤感情”?下面是完整的设计与实现方案。

1. 实际应用场景描述

场景: 中式婚礼现场。

人物: 新郎新娘、双方父母、负责收钱的七大姑八大姨(记账人)。

过程: 婚礼当天宾客络绎不绝,有人随了 1000 元现金,有人在微信转账,还有人托人代交。忙乱中,记账人漏记了一笔,或者把“张总”记成了“张生”。事后,新人想感谢宾客,却拿不出准确的名单;亲戚间甚至流传出“某人明明给了 2000,账上怎么才 1000”的谣言。

解决方案: 引入“婚礼礼金链”。每一笔礼金入账,都生成一个包含时间、金额、送礼人、备注(如是否回礼)的区块。新人拥有私钥,宾客可以通过特定链接查询自己的记录,实现“公开透明,不可篡改”。

2. 引入痛点

1. 中心化记账易出错: 传统纸质记账或 Excel 表格,容易漏记、错记,且事后无法追溯修改痕迹。

2. 信任危机: 涉及金钱,一旦账目不清,容易引起亲友猜疑(怀疑记账人私吞或偏心)。

3. 隐私与公开的矛盾: 完全公开所有人的礼金数额可能引发攀比或尴尬;完全保密又不利于监督。

4. 回礼管理混乱: 婚礼后回礼(发喜糖、送礼物)没有依据,容易漏掉重要的宾客。

3. 核心逻辑讲解 (创新点)

本项目采用“私有链 + 选择性披露 (Selective Disclosure)”的架构:

* Merkle Tree 隐私保护: 我们不把每一笔礼金详情对所有人都公开。相反,我们使用默克尔树 (Merkle Tree)。所有人可以验证账本是完整的(没有凭空消失的钱),但只有送礼人自己(通过私钥或特定哈希)才能查询到自己的具体金额。

* 双人确认机制: 每一笔大额礼金(如超过 1000 元),需要两位见证人(如新郎和新娘)的签名确认,防止单人作恶。

* 资产映射: 礼金不仅仅是钱,未来可能涉及“回礼义务”。我们在区块中记录

"gift_status"(是否已回礼),形成闭环。

4. 代码模块化实现

项目结构如下:

wedding_ledger/

├── app.py # FastAPI Web 应用入口

├── blockchain.py # 区块链核心逻辑

├── crypto_utils.py # 加密工具 (哈希、Merkle Tree)

├── models.py # Pydantic 数据模型

└── README.md

4.1 crypto_utils.py (加密工具)

import hashlib

import json

def calculate_hash(data: dict) -> str:

"""计算字典数据的SHA-256哈希"""

data_string = json.dumps(data, sort_keys=True)

return hashlib.sha256(data_string.encode()).hexdigest()

def get_merkle_root(hashes: list) -> str:

"""

计算默克尔树根哈希

这是实现隐私保护的关键:根哈希代表整个账本的完整性

"""

if not hashes:

return ""

if len(hashes) == 1:

return hashes[0]

new_hashes = []

for i in range(0, len(hashes), 2):

left = hashes[i]

right = hashes[i+1] if i+1 < len(hashes) else left

new_hashes.append(calculate_hash({"left": left, "right": right}))

return get_merkle_root(new_hashes)

4.2 models.py (数据结构)

from pydantic import BaseModel

from typing import Optional

from datetime import datetime

class GiftRecord(BaseModel):

"""礼金记录模型"""

guest_name: str # 宾客姓名

amount: float # 礼金金额

gift_time: datetime # 送礼时间

note: Optional[str] = "" # 备注 (如:送了一套茶具)

is_returned: bool = False # 是否已回礼

4.3 blockchain.py (核心逻辑)

from .crypto_utils import calculate_hash, get_merkle_root

from .models import GiftRecord

from datetime import datetime

class WeddingBlock:

"""

婚礼礼金区块

"""

def __init__(self, index, previous_hash, gift_record: GiftRecord, signatures: list):

self.index = index

self.timestamp = datetime.now().isoformat()

self.gift_record = gift_record

self.signatures = signatures # 见证人签名列表 (简化版用地址代替)

self.previous_hash = previous_hash

self.hash = self.calculate_self_hash()

def calculate_self_hash(self):

"""计算区块哈希"""

block_content = {

"index": self.index,

"timestamp": self.timestamp,

"gift_record": self.gift_record.dict(),

"signatures": self.signatures,

"previous_hash": self.previous_hash

}

return calculate_hash(block_content)

def to_dict(self):

return {

"index": self.index,

"timestamp": self.timestamp,

"gift_record": self.gift_record.dict(),

"signatures": self.signatures,

"previous_hash": self.previous_hash,

"hash": self.hash

}

class WeddingLedger:

"""

婚礼礼金账本 (私有链)

"""

def __init__(self, couple_addresses: list):

self.chain = []

self.couple = couple_addresses # [新郎地址, 新娘地址]

self.create_genesis_block()

def create_genesis_block(self):

"""创世区块:婚礼誓言"""

genesis = WeddingBlock(

index=0,

previous_hash="0",

gift_record=GiftRecord(guest_name="Genesis", amount=0.0, gift_time=datetime.now(), note="Wedding Day!"),

signatures=[]

)

self.chain.append(genesis)

def add_gift(self, gift_record: GiftRecord, signer_address: str) -> WeddingBlock:

"""

添加礼金记录

:param signer_address: 见证人地址 (必须是新郎或新娘)

"""

if signer_address not in self.couple:

raise PermissionError("Only the couple can sign the record.")

last_block = self.chain[-1]

new_block = WeddingBlock(

index=len(self.chain),

previous_hash=last_block.hash,

gift_record=gift_record,

signatures=[signer_address]

)

self.chain.append(new_block)

return new_block

def get_merkle_root(self) -> str:

"""获取当前账本的默克尔根,用于验证完整性"""

hashes = [block.hash for block in self.chain]

return get_merkle_root(hashes)

def get_total_amount(self) -> float:

"""计算礼金总额"""

total = 0

for block in self.chain[1:]: # 跳过创世区块

total += block.gift_record.amount

return total

4.4 app.py (API 接口)

from fastapi import FastAPI

from .blockchain import WeddingLedger

from .models import GiftRecord

from datetime import datetime

app = FastAPI()

# 初始化账本 (新郎新娘的地址)

ledger = WeddingLedger(couple_addresses=["0xBride", "0xGroom"])

@app.post("/gift/record")

def record_gift(guest_name: str, amount: float, note: str, signer: str):

"""记录礼金"""

gift = GiftRecord(

guest_name=guest_name,

amount=amount,

gift_time=datetime.now(),

note=note

)

block = ledger.add_gift(gift, signer)

return {

"message": "礼金记录已上链,不可篡改!",

"block_info": block.to_dict()

}

@app.get("/ledger/summary")

def get_summary():

"""查询账本摘要"""

return {

"total_gifts": len(ledger.chain) - 1,

"total_amount": ledger.get_total_amount(),

"merkle_root": ledger.get_merkle_root()

}

5. README 文件与使用说明

WeddingLedger (婚礼礼金链)

一个基于区块链的透明、不可篡改的婚礼礼金记账系统,旨在消除家庭财务纠纷。

核心特性

* 双人见证: 每一笔礼金需要新郎或新娘确认,防止记账错误。

* 链式存储: 利用区块链特性,确保历史记录无法被涂改。

* 数据完整性: 通过 Merkle Root 可以快速验证账本是否被篡改。

使用流程

1. 启动服务

uvicorn app:app --reload

2. 记录礼金婚礼现场,每收到一笔礼金,记账人(如伴郎)通过接口记录:

curl -X POST "http://localhost:8000/gift/record?guest_name=王叔叔&amount=2000&note=送了花瓶&signer=0xGroom"

3. 查看汇总

curl http://localhost:8000/ledger/summary

6. 核心知识点卡片

知识点 解释

Merkle Tree (默克尔树) 用于高效验证大数据集的完整性,是实现隐私保护的关键技术。

Permissioned Chain (许可链) 不同于比特币的公链,本系统属于私有链,只有授权的人(新人)才能写入数据。

Digital Signature (数字签名) 确保记账行为的不可否认性,是谁记的账,谁就要负责。

Audit Trail (审计追踪) 区块链天然提供了完整的操作日志,便于事后审计。

Data Integrity (数据完整性) 保证数据在传输和存储过程中未被意外或恶意修改。

7. 总结

作为一名全栈工程师,我认为这个项目是区块链技术在人情社会中最温情的落地应用之一。

* 技术降维打击: 我们用 Merkle Tree 这种高级密码学工具,解决了一个看似简单的 Excel 记账问题,展示了技术的优雅。

* 社会学意义: 在中国的人情社会中,“面子”和“信任”极其重要。传统的“糊涂账”往往是因为缺乏一个中立的第三方。区块链在这里充当了那个“永不撒谎的中间人”。

* 产品哲学: 好的技术不一定要炫技。将复杂的区块链逻辑封装在后台,给前端用户(记账人、宾客)提供一个极简的界面,这才是技术布道的正确姿势。

从此,婚礼不再有“糊涂账”,只有甜蜜的回忆和清晰的账目!

利用AI解决实际问题,如果你觉得这个工具好用,欢迎关注长安牧笛!

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/4/24 20:27:36

卷积神经网络(CNN)原理与实战:从入门到图像分类

1. 卷积神经网络速成指南&#xff1a;从原理到实战第一次接触卷积神经网络(CNN)时&#xff0c;我被那些专业术语搞得晕头转向——卷积核、池化层、特征图...直到自己动手实现了一个识别手写数字的模型&#xff0c;才真正理解这些概念的意义。本文将用最直白的语言&#xff0c;带…

作者头像 李华
网站建设 2026/4/24 20:25:20

关联、压缩与承担:从缘起性空到AI时代的决断劳动

关联、压缩与承担&#xff1a;从缘起性空到AI时代的决断劳动如果从更基础的角度理解世界&#xff0c;我们或许可以放弃“因果”这一看似坚固的概念&#xff0c;转而承认&#xff1a;世界首先呈现为一种无穷展开的关联之网。所谓因果&#xff0c;不过是认知系统对这种复杂关联的…

作者头像 李华
网站建设 2026/4/24 20:24:24

ESP-IDF C++ RTTI实战指南:突破类型限制的终极解决方案

ESP-IDF C RTTI实战指南&#xff1a;突破类型限制的终极解决方案 【免费下载链接】esp-idf Espressif IoT Development Framework. Official development framework for Espressif SoCs. 项目地址: https://gitcode.com/GitHub_Trending/es/esp-idf ESP-IDF&#xff08;…

作者头像 李华
网站建设 2026/4/24 20:22:55

当爱因斯坦的‘简单生活’哲学遇上极简主义开发:如何用更少的代码、更清晰的架构创造价值

当爱因斯坦的‘简单生活’哲学遇上极简主义开发&#xff1a;如何用更少的代码、更清晰的架构创造价值 在代码行数成为KPI、技术栈复杂度日益攀升的今天&#xff0c;开发者们常陷入一种悖论&#xff1a;我们使用更多工具解决由工具产生的问题。这让人想起爱因斯坦书桌上那个著名…

作者头像 李华
网站建设 2026/4/24 20:20:58

Transformer位置编码原理与Keras实现详解

1. Transformer位置编码层深度解析在自然语言处理领域&#xff0c;Transformer模型彻底改变了序列建模的范式。与传统RNN不同&#xff0c;Transformer完全依赖注意力机制来捕捉序列关系&#xff0c;这就引出了一个关键问题&#xff1a;如何在没有循环结构的情况下表示序列中元素…

作者头像 李华