最新

大多数“开放金融”项目只停留在账户聚合层面。 但当你尝试基于保险 API 进行构建时，你会很快遇到各种问题： 没有真正的报价工作流程，没有同意流程，也没有符合 FAPI 标准的身份验证。 所以我构建了一个阿联酋开放金融保险测试后端。 它模拟了完整的生命周期： OAuth2 FAPI 风格的身份验证（JWT） 同意创建和授权 跨 7 种保险类型的报价生成 报价 → 保单转换 Webhook 事件和错误处理 示例流程： 创建同意 → 生成报价 → 接受 → 签发保单。 它已 Docker 化，具有 Swagger 文档，旨在模拟真正的第三方提供商（TPP）的集成方式。 这是一个测试后端，不是生产基础设施。 很好奇其他人集成开放银行/保险 API 时遇到的最大难题是什么。

Hi HN， 我一直在研究一种区块链设计，它在解决 51% 攻击问题上采用了不同的方法。它没有像传统系统那样通过硬件或资金来立即提高攻击成本，而是让攻击在结构上执行缓慢，进而使其代价高昂且难以长期维持。 核心思想很简单：（1）每个节点/身份在工作量证明过程中被限制在约 1 次哈希/秒，无论硬件如何（2）消除并行挖矿优势（无法共享工作量）（3）将影响力转移到持续的、持久的参与，而不是原始的算力（4）使批量生成女巫身份变得缓慢、昂贵且困难。 我已经构建了一个基于浏览器的 MVP，演示了受限工作量证明模型（作为参考实现）：<a href="https://grahambell.io/mvp/Proof_of_Witness.html" rel="nofollow">https://grahambell.io/mvp/Proof_of_Witness.html</a> 这里还有一个简短的演示（受限工作量证明）：<a href="https://youtu.be/i5gzzqFXXUk?si=y_Pv5ZDv9SGhRFjY" rel="nofollow">https://youtu.be/i5gzzqFXXUk?si=y_Pv5ZDv9SGhRFjY</a> 网站：<a href="https://grahambell.io/" rel="nofollow">https://grahambell.io/</a> 好奇这种方法听起来是否有趣，或者您是否认为它立即就存在问题。 和平