个人使用体验感觉挺好用的，作为 block 助手足够使用
欢迎使用链接注册 asksurf.ai/?r=VXXJHKCULU6T
]]>然后想到自己闲置的服务器上一直跑的有 eth 和 btc 地址生成。我是把生成的都存起来了，所想想看看能不能找个后缀是 V2EX 的，于是写了个脚本，在已经生成的地址里面找 V2EX 后缀的，发现 btc 的有，但是 eth 的没有，百思不得其解的时候想到 eth 地址是 16 进制的，不可能存在 v 和 x 字符....
找到带 V2EX 后缀的 btc 钱包地址
bc1qas84nh6kl6js6pa9gafs4ay93smrye6lwwv2ex bc1q9rlp3fq5wurrc98l6vagd6r4eccfck2uv0v2ex bc1q44q9d6lx95l46k2cmxljk4khjwn7256egjv2ex bc1qtyrylkg8vv7eg82xr5t7973nepa7u4nhu2v2ex bc1qt7yvfgg9t42ada70fqkckhu83r9acfd69lv2ex bc1qs84ypeukgrg896g6z6dn6f26fnvulp8vv6v2ex 发现还不少
]]>我在想有没有在付出 cpu/gpu 的计算力的时候，做一些有意义的事情，并获取到代币（比如$v2ex ）
我 yy 了一个想法：
比如设计一个种子，种子中描述了一个计算类的任务（比如训练/推理等任务）+完成的代币奖励数额
一个类似迅雷一样的软件，导入这个种子的人就可以联合完成这个任务，参与的人越多完成的越快
完成后按自身完成占比获取代币 发布种子（内含代币报酬）的人也可以拿到自己的模型/结果
这个想法现实不？
]]>这是一个使用 Fyne 框架在 Sui 区块链上构建去中心化应用 (dApp) 的模板项目。它演示了如何创建一个与 Sui 智能合约交互的跨平台应用（桌面、Web 和移动端）。
sui-go-sdk 与 Sui 区块链进行交互。]]>项目地址sui-go-dapp 欢迎 star
官网介绍： https://www.kraken.com/zh-cn/krak
现在的话，支持的法币数量还比较少（官方说的会支持全球 160 多个国家/地区），krak card 也还没有上线（这个卡知否支持大陆还不确定），但是现在注册门槛低（支持中国大陆，不需要地址证明），新用户注册以后充值 10 美金就可以获得 10 美金奖励。
详细的注册流程可以看： https://www.ajie.lu/article/2247d549-6f33-80cd-8cd1-d0bc22037d11
]]>在区块链监控的世界里，速度就是一切。当 BSC （ Binance Smart Chain ）决定将区块时间从 3 秒缩短到 1.5 秒，甚至计划在 2025 年 6 月 30 日进一步降至 0.75 秒时，我的监控系统面临了前所未有的挑战。这是一个关于如何将一个"气喘吁吁"的监控器改造成"风驰电掣"的高性能系统的故事。
故事开始于一个平静的下午，突然我的 BSC 监控器开始出现诡异的行为：
处理耗时 155.70s ，可能跟不上出块速度 3 处理耗时 70.95s ，可能跟不上出块速度 3 处理耗时 65.84s ，可能跟不上出块速度 3 处理耗时 60.87s ，可能跟不上出块速度 3 RPC 调用频率过高: 4.61/s ，超过建议值 1.0/s 处理区块 51779957 时出错: Block with id: '0x3161975' not found. 这简直是一场灾难！ 原本应该在 3 秒内完成的区块处理，竟然需要155 秒（ 2 分 35 秒）！最夸张的是，单个区块处理时间最长达到 155.70 秒，这意味着当我处理完一个区块时，BSC 链已经又产生了 52 个新区块。我的监控器彻底"迷失"在了区块链的时间长河中。
经过深入分析日志，我发现了问题的根源：
get_block调用需要 1.7-2.7 秒通过日志分析，我统计出了这场"性能灾难"的恐怖数据：
当时的系统状态可以用"绝望"来形容——每处理一个区块要花费几十秒甚至几分钟，而 BSC 每 3 秒就产生一个新区块。我陷入了永远追不上的恶性循环，仿佛一只蜗牛试图追赶一辆跑车。
通过详细的性能分析，我制作了一个"犯罪现场"报告：
# 性能分析报告 瓶颈排行榜: 1. RPC 调用 get_block: 1.7-2.7 秒 (占总时间 90%) 2. 交易解析: 0.002 秒 (几乎可以忽略) 3. 网络延迟: 不固定 问题诊断: - 单 RPC 端点成为性能瓶颈 - BlockNotFound 错误频发 (追得太急) - 没有合理的错误处理策略 - 缺乏 RPC 超时控制 这个分析让我恍然大悟：真正的敌人不是代码逻辑，而是网络 IO ！ 交易解析速度快得惊人（ 0.002 秒），而 RPC 调用却慢得要命。
基于诊断结果，我制定了一个分阶段的优化计划：
第一阶段：紧急止血
第二阶段：架构升级
第三阶段：精细调优
我的第一个大招是实现多 RPC 端点管理器：
# 从单一端点的绝望... rpc_url = "https://bsc-dataseed1.binance.org" # 到多端点的希望！ rpc_urls = [ "https://bsc-rpc.publicnode.com", "https://bsc.meowrpc.com", "https://bsc-dataseed1.binance.org", "https://bsc-dataseed2.binance.org", "https://bsc-dataseed3.binance.org", "https://bsc-dataseed4.binance.org", "https://rpc.ankr.com/bsc/..." ] 这个改变带来了立竿见影的效果：
接下来，我引入了并发处理机制：
# 老式的串行处理（慢如蜗牛） for block_number in range(start, end): await process_block(block_number) # 40 秒/区块 # 新式的并发处理（快如闪电） tasks = [] for block_number in range(start, min(start + 10, end)): task = process_block_concurrent(block_number) tasks.append(task) results = await asyncio.gather(*tasks) # 最多同时处理 10 个区块 并发处理让我能够同时处理多个区块，将原本需要顺序执行的操作变成了并行操作。
最关键的改进是修复了 BlockNotFound 错误的处理逻辑。**问题的根源在于"追赶模式"**：
当监控器落后太多区块时，系统会进入"疯狂追赶"模式，试图快速处理大量区块。这种急躁的行为导致：
# 追赶模式的恶性循环 当前区块: 1000 最新区块: 1050 ← 落后 50 个区块！ 系统反应: "我要赶紧追上！" → 疯狂请求区块 1001, 1002, 1003... 1050 → RPC 服务器压力过大，开始返回错误 → BlockNotFound 频繁出现 → 系统跳过"未找到"的区块 → 数据完整性受损！ 真相：这些区块并非真的"不存在"，而是 RPC 服务器在高压下的"拒绝服务"表现。更深层的动机是：我不喜欢看到满屏的 BlockNotFound Error ，而且隐隐担忧这样猛烈的获取最新数据会被 RPC 服务商限制流量。
# 之前的错误处理（会跳过区块） try: block = await get_block(block_number) process_block(block) block_number += 1 # 无论成功失败都递增！危险！ except BlockNotFound: logger.error(f"区块 {block_number} 未找到") block_number += 1 # 跳过了区块！造成数据缺失 # 改进后的处理（绝不跳过区块） try: block = await get_block(block_number) process_block(block) block_number += 1 # 只有成功才递增 except BlockNotFound: logger.debug(f"区块 {block_number} 未找到，等待下次重试") break # 停止处理，下次循环重试同一区块，绝不跳过 我彻底改变了系统的"急躁"性格：
# 新的哲学：保持合理距离，不要急于追赶 if blocks_behind <= 12: # "佛系"模式：不急不躁，稳步前进 target_block = current_block + 1 logger.debug(" 落后不多，佛系处理模式") else: # 即使落后很多，也要控制节奏 logger.info(" 启用温和批量处理模式") 这个看似简单的改变解决了系统跳过区块的严重问题，关键在于理解了 BlockNotFound 的真实含义：不是区块不存在，而是我太急了！
我实现了一个"佛系"同步策略——不再急于追上最新区块，而是保持合理的距离：
# 智能同步逻辑 blocks_behind = latest_block - current_block if blocks_behind <= 12: # 落后不多，正常处理模式 target_block = current_block + 1 logger.debug(f" 落后{blocks_behind}个区块，正常处理模式") else: # 落后太多，批量处理模式 target_block = latest_block logger.info(f" 落后{blocks_behind}个区块，启用批量处理模式") 这个策略的精妙之处在于：
我添加了双重超时保护：
# 配置文件 rpc_timeout: 5 # RPC 调用超时时间(秒) block_time: 1.5 # 目标出块时间(秒) # 代码实现 timeout = getattr(self.config, 'rpc_timeout', 5) provider = AsyncWeb3.AsyncHTTPProvider( url, request_kwargs={'timeout': timeout} ) 我引入了backoff_blocks配置，让系统启动时不会立即追最新区块：
# 启动时的智能退让 latest_block = await rpc_manager.get_cached_block_number() backoff_blocks = getattr(self.config, 'backoff_blocks', 10) start_block = max(0, latest_block - backoff_blocks) logger.info(f" 最新区块: {latest_block}, 向后退{backoff_blocks}个区块, 起始监控区块: {start_block}") 这确保了系统启动时有足够的"缓冲区"，不会一开始就陷入追赶模式。
经过一系列优化后，我的 BSC 监控器脱胎换骨：
| 指标 | 优化前 | 优化后 | 改善幅度 |
|---|---|---|---|
| 最长处理时间 | 155.70 秒 | ~1.3 秒 | 99.2%提升 |
| 平均处理时间 | 50-60 秒 | ~1.3 秒 | 97.8%提升 |
| 超时案例数量 | 70 个(40s+) | 0 个 | 100%消除 |
| RPC 端点数量 | 1 个 | 7 个 | 700%增加 |
| 并发处理能力 | 串行 | 最多 10 个区块同时 | 1000%提升 |
| BlockNotFound 错误 | 频繁 | 几乎消失 | 99%减少 |
| 落后区块数 | 50+ | 5-10 | 90%改善 |
| RPC 调用频率 | 4.61/s | 0.77/s | 83%优化 |
优化后的日志显示了系统的华丽转身：
同步检查 - 当前处理到区块: 51782372, 最新区块: 51782382, 落后: 10 获取区块 51782373 交易数据耗时: 1.267s, 交易数: 392 (RPC: bsc.meowrpc.com) 解析区块 51782373 交易耗时: 0.001s, 总交易: 392, 发现相关交易: 0 完成处理区块 51782373 总耗时: 1.268s (获取+解析+处理) 处理 1 新区块 | RPC: 19 (0.77/s) | 缓存命中率: 40.0% | 活跃端点: 7/7 可用 从这些日志可以看出：
或许最大的成就是日志变得"安静"了。以前满屏的警告和错误消息消失了，取而代之的是井然有序的处理记录。没有了刺眼的红色 ERROR ，没有了令人焦虑的 WARNING ，只有绿色的 SUCCESS 和蓝色的 INFO 。
这种"宁静"代表着系统的成熟和稳定。
2025 年 6 月 30 日，BSC 将实施 Maxwell Hard Fork （ BEP-524 ），将区块时间进一步缩短至 0.75 秒。这意味着：
我已经为这个挑战做好了准备：
# 0.75 秒时代的配置 block_time: 0.75 max_concurrent_blocks: 15 # 从 10 增加到 15 sync_check_interval: 12 # 从 15 调整到 12 rpc_timeout: 3 # 更严格的超时控制 我正在研究的下一代优化技术：
通过这次优化经历，我总结出了几个核心原则：
优化系统就像调音钢琴——需要精细的调整和敏锐的听觉。每个参数的改变都可能产生连锁反应，关键是找到各个组件之间的和谐平衡。
我学会了：
这次优化带来了一些意外的收获：
回顾这段优化历程，我不禁感慨技术进步的魅力。一个曾经"气喘吁吁"的系统，通过精心的诊断、设计和实施，最终变成了一个"风驰电掣"的高性能监控器。
从 40 秒到 1.3 秒，从单 RPC 到多端点，从串行到并发，从慌乱到有序——这不仅仅是性能的提升，更是系统设计思维的跃升。
当我看着监控器现在安静而高效地工作，处理着每 1.5 秒一个的 BSC 区块，我知道这个系统已经准备好迎接即将到来的 0.75 秒挑战。
正如一位智者说过："优化不是让代码跑得更快，而是让系统变得更智能。"
我的 BSC 监控器现在确实变得更智能了——它知道何时等待，何时前进，何时坚持，何时变通。这就是一个成熟系统应有的智慧。
这个故事献给所有在深夜里与性能问题搏斗的工程师们。记住，每一次优化都是一次成长，每一个瓶颈都是一个机会。
故事统计：
以下是在优化过程中的一些关键对话和决策时刻：
User: "我看到才落后 10 的时候就批量处理了，我不是允许落后 12 个嘛" Assistant: 发现了同步逻辑的问题，修复了批量处理触发条件 User: "当 rpc 调用失败我不应该 +1" Assistant: 这是核心问题！修复了 BlockNotFound 时跳过区块的严重 bug User: "追赶模式会导致 rpc 经常报错 BlockNotFound" Assistant: 恍然大悟！ BlockNotFound 不是区块不存在，而是我追得太急了 User: "需要对 rpc 做超时处理 定义在配置文件 最多 10 秒 否则我赶不上最新区块" Assistant: 添加了 rpc_timeout 配置和双重超时保护 User: "为了避免 对 rpc 追的太着急，我启动的时候直接落后 10 个区块进行处理" Assistant: 实现了 backoff_blocks 机制，启动时智能后退 User: "我现在使用了轮询 rpc 的方案，这里是否需要调整" Assistant: 优化了多 RPC 环境下的配额计算逻辑 User: "这里的处理耗时太笼统了" Assistant: 改进了日志，分别显示获取、解析、总处理时间 User: "还是追的太快了 落后: 0" Assistant: 调整了智能同步策略，保持 5-10 个区块的合理距离 User: "经过一系列优化，日志里终于没有令人讨厌的 warnings 了" Assistant: 成功消除了所有误报警告，系统运行平稳 BlockNotFound 处理策略
问题："追赶模式会导致 rpc 经常报错 BlockNotFound" 真相：BlockNotFound 不是区块不存在，而是 RPC 服务器压力过大的表现 动机：我不喜欢看到满屏的 BlockNotFound Error ，担心被 RPC 服务商限流 方案：不递增区块号，下次循环重试同一区块，避免跳过数据 影响：彻底解决了跳过区块的问题，保证数据完整性 智能同步策略
问题："落后≤12 个区块时不应该批量处理" 方案：分级处理策略，保持合理距离 影响：避免了过度追赶导致的错误 多 RPC 架构
问题："单 RPC 成为性能瓶颈" 方案：7 个 RPC 端点轮询 + 故障转移 影响：响应时间从 2.7 秒降到 0.4-1.2 秒 启动缓冲机制
问题："启动时立即追最新区块容易出错" 方案：backoff_blocks=10 ，向后退 10 个区块 影响：系统启动更稳定，避免初始错误 User: "重启服务检查日志确认" Log: 完成处理区块 51782373 总耗时: 1.268s Log: RPC: 19 (0.77/s) | 缓存命中率: 40.0% | 活跃端点: 7/7 可用 最终结果：从 155 秒超时到 1.3 秒稳定处理，性能提升 99.2% 最后更新：2025-06-20
技术栈：Python + AsyncIO + Web3.py + Multi-RPC + 大量的耐心、烟草和茶水
Agent Network 里有很多的 Agent ，Agent 之间通过 A2A 进行通信。
目前能想到的一些问题:
A2A 协议中，只定义了如何描述和通信，对于如何发现可信的 Agent 、以及如何完成支付，就是自然的问题了。
网页数量是万亿的，Agent 假设未来有 10 亿个 Agent ，哪些 Agent 比较可信呢？根据什么来判断呢？
所以，会有一些 router ，对 Agent 进行分发、路由。这些信息存在 blockchain 中，是否有必要？
可能不大。但 Agent 之间的支付呢？ Agent 不会一直免费。
比如，我完成一件事情，Agent-A 需要调用其他的 10 个 Agent 才能完成，我支付给 Agent-A ，Agent-A 支付给其他的 Agent ，这种机器和机器之间的结算，可能 blockchain 是一个机会，机会不是炒币，是真的作为一个基础设施在发挥作用。
那，Agent 之间的支付，是最确定的了。
思考还不够体系，只是感觉 blockchain 的可信，安全，去中心化，可能不匹配人类，人类顶多用来炒币。 但对 AI Agent 来说，就是顺了。
]]>
按照 TG 小程序里面任务，从现在开始到 25 年 1 月每天登录签到可以得到 1 个 SOL ，现在一个的价格是 200 多美元，这样是不是太轻松了？
]]>我没有解密查看网站发送的加密信息到底是什么内容,不过这种场景下直接按私钥看待保证不会冤枉一个.
包括但不限于 https://raretrx.pro/ (这个还很多网站推荐的,结果是个黑的)
https://www.onefish.work/ (刚开始发现没 xhr 以为干净的,没想到再看发现用的 ws 传输的)
https://viptrx.pro/
https://rareeth.pro ...
由于钓鱼站实在太多,以上只是几个示例
另外发现不少网站的模板类似而且后门提交地址都是 /robotVerification ,怀疑是某些团队模板化批量建了大量钓鱼站,请大家小心鉴别
]]>之前每次上涨，都会有几个热度很高的讨论帖，但这次很反常啊，几乎没有见到 V 友讨论。
]]>请问大家有没有适合初学者入门的项目推荐？
]]>我的感觉是现在区块链好像没人提了, 不知未来发展如何, 请业内人士指点现在学区块链 blockchain 的话, 将来有(钱)前景吗?
谢谢
]]>使用加密货币购买淘宝商品，各种礼品卡
]]>什么无许可、不要相信去验证、去中心化、不可篡改之类的神奇特性的背后的实现其实不是很难理解，不过确实改变了很多。
]]>既然 USDT 有黑名单机制，是不是用比特币更好？
]]>最近比较多的需求是做空投自动化的开发，类似自动化测试，模拟人的操作。这个我不懂，听着空投暴富的故事倒是不少，但是不理解，即使可能赚钱，也不可持续。
还有空投这个业务的核心是技术能力么？
]]>1 、是否以太坊上的所有节点都有 EVM ？
2 、一个人编写好的智能合约代码是否要用私钥签名然后发送给所有节点？在取得共识后打包进以太坊区块？
3 、当智能合约被调用开始运行后是“仅仅运行在某一个节点的服务器上”？ 还是所有节点的服务器都要同步运行？
4 、假设智能合约的运行结果如果是一次以太币转账。那么如何完成转账的私钥签名并发送到全网的？
5 、智能合约是代码既合约。那么图中右下角那个普通用户如何保证他在前端看到的文字版的合约条款与后台运行的智能合约是完全相符的？（你不能要求所有前台用户都会读智能合约的代码吧）
6 、如果有大量智能合约占用节点的内存（假设运算次数少但常驻内存，因此不会消耗多少 gas ）那么节点的内存会不会不够用？
目前我的疑问诸如此类。之所以没有找到答案是因为：目前我找到的书籍或视频资料。要么是泛泛而谈“智能合约运行在以太坊的区块链上”，要么就直接开始讲代码编写。基本没有涉及到智能合约详细“运行原理”的讲解。不知道各位老师 有没有这方面的学习资料推荐？
请看上面这个链接。老师说通过 block header 和 nonce 算出一个“初始的哈希值”。根据这个哈希映射到大数据集中的某个位置。请问是通过什么规则将“初始的哈希值”映射到大数据集中的某个位置呢？所谓“大数据集中的某个位置”是内存地址吧？（根据老师讲课的后文，我认为应该是内存地址）。
但是这个大数据集在每台设备中都有不同的内存地址区间。怎么能保证不同设备的“初始的哈希值”就一定能映射到大数据集中的同一个位置呢？如果不能做到！那么其他节点在验证最新发布的区块时如何验证该 block 给出的 nonce 符合预设的难度要求呢？
还有一开始计算的”大数据集的 cache“是由一个 seed 生成的。那么这个 seed 又是谁给出？或者是按照什么规则生成的呢？
]]>老师说全节点在收到一个交易记录的时候首先会根据 UTXO 去检查输入方的比特币来源。比如下面这个交易。在审查 B->C 交易的时候要根据 B 提供的哈希指针去验证 B 的比特别来源。如果发现在发起 B->C 交易之前，B 已经将比特币转给 D 了。那么就认为这是“双花”或者说“透支” ，则会拒绝将 B->C 交易打包！
关于这个流程我有两个疑问：
1 、老师给出的例子是 A->B 5 个比特币（假设 B 只有 5 个比特币）。然后 B->D 5 个比特币。最后 B->C 5 个比特币。根据交易记录的哈希指针可以发现 B->D 的交易。 -----这我就不明白了。如下图：既然 B->C 的 Vout 哈希指针指向的是 B 作为输出角色（收款方）的那一笔交易记录。那么如何根据这个哈希指针发现 B->D 的交易记录呢？ B->D 的交易，B 作为输入也会有一个哈希指针指向 A->B 的交易的输出方。但是 B->C 的交易去向 A->B 的 vout 查询时如何能发现 B->D 的交易呢？
2 、假设 B->D 的交易确实发生了。但是金额只有 2 个比特币。那么 B 此时剩余 3 个比特币。在假设第三笔交易 B->C 的交易额是 3 个比特币。那么交易应该是合法的。但是全节点如何通过这些哈希指针完成定量审核的呢？ 