Bytom Dapp 开发笔记(一):架构设计
简介
研究比原链已经一年了,用比原链做了几个dapp,而且最近还做了一个基于他们插件钱包的dapp,总结了一些遇到的坑,还有一些技术细节,接下来我会分成三章,从dapp设计架构上,到深入到源码分析去帮各位介绍一下比原链的dapp,还有分析比原官方最近发布的dapp的架构。
Dapp架构设计
这个是所有工作的基础,从看完比原链源码使用过比原的钱包后,我们就在思考比原链的dapp如何做,应该说是区块链应用应该如何做,我们之前尝试过用以太坊、比特币、超级账本去做dapp。先总结一下区块链dapp的痛点:
1)没办法保证上链前数据的真实性;
2)Tps很低;
3)接入成本高,需要自己搭建节点;
Dapp架构方案
我现在总结了两个基于比原链的dapp架构方案:(如果有新版或者比较好的解决方案欢迎交流)
Dapp肯定离不开复杂的业务,所以肯定会用到比原链的智能合约,以下方案都支持智能合约。
一、搭建区块链node
其实就是自己搭建个节点,然后应用直接调用节点提供的接口,完成了区块链的业务内容,比原链的源码整合了钱包功能,搭建也比较方便,几句代码就可以搭建完了,但是这样的业务视乎不大合理,因为这种后端整合比原源码钱包(以下称为“pc钱包”)的方式,相当于把所有的账户信息都托管给dapp,其实就是一个集中的官方的钱包,所有的账户都归官方管,这样会有中心化问题,最后会被怀疑用不用这个区块链是否有必要。
比原链自己有一套用户的模块,用户可以使用pc钱包、客户端钱包、手机钱包等,自己的用户信息可以自己备份,交易信息全部公开全部可以到区块链浏览器里面查到。这个方案只是主要实现了交易上链。
ps: 当然其实还是可以变通一下,就是说把PC钱包的所有接口在dapp实现一次,然后结合业务,但是比原的源码是会不断更新,还要随着它的版本更新,然后更新自己的应用,显然不实际。
说一下里面的坑:
1)账户BTM问题,这种方案每个dapp账户底层都要绑定一个钱包的用户,可以展现地址用户自己充值、直接在dapp里面充值、完成任务派送这些等,但是初始化账户拥有BTM需要有时间过程,正常应用这样的体验,早就让用户关闭了。
2)UTXO问题,比原链是基于utxo未花费输出交易模型,当自己的UTXO参与的交易没有确定是无法使用的,但是dapp这里绑定的用户,不能保证他有足够多的UTXO,除非自己转账的时候让他拆分,否则会类似单线程的操作,也是比较慢。
3)用户无法获取自己的私钥,在比原链PC钱包,是一套私钥,派生多个账号这样,就是说一个钱包就一套私钥,这个不能给用户。这样又违背了区块链的去中心化的问题。
总的来说,这个方案是单纯保证了dapp交易上链,但是各方面明显不足。
二、插件钱包(Byone)方案
这个方案是今年比原链推出的dapp新型的解决方案,有解决到方案一的痛点,这个也是我比较提倡的方案,现在比原链的智能合约功能已经非常强大,如果做复杂的dapp,用这个方式比较好。
简单来说就基于chrome开发了一个插件钱包,安装完插件,用户直接可以创建账户,使用账户的转账功能,里面有BTM的转账功能,账户的备份功能....是比较完整的一个钱包,这个钱包最大的作用就是包含了丰富的开发者api,可以支持开发者去实现智能合约交易。
我们重点说一下这个结构的技术原理,如图
1)Dapp前端,就是前端页面,插件钱包是基于chrome的,所以这里代表的就是新的页面集成了插件钱包(Byone)的api。
2)Byone,就是在chrome应用商店里面可以搜索到,点击安装就行,当前版本是2.0.0,非常好用。
3)Bufferserver服务器,官方提供demo里面这模块属于缓存服务器,其实这个应该改成Dapp后端,实际业务逻辑还有很多需要后端辅助,例如排行榜、非BTM比原资产交易等。(这块后面重点开一章去说清楚),现在理解称为后端就可以。
4)Blockcenter,其实就是官方提供的服务,直接提供接口可以触发比原链的交易功能,这样解决了上面的方案,避免需要自己搭建node节点,让dapp开发者更加容易接入。
总结
两套方案里面,方案一个人认为属于早期的方案,随着比原链的发展,我们可以适当了解有助于我们理解比原链的架构设计,而且在方案二里面,也一定要用到PC钱包,它可以协助我们开发者提高开发效率100倍,没有夸张,是100倍。
插件钱包现在还在推广还有完善当中,不过功能已经非常成熟了,所以Dapp开发者赶紧抓紧去使用来开发属于自己的dapp吧。
下一章我们重点说一下Dapp的开发流程。以及遇到的一些坑,还有粘贴源码。
作者:天才的饭桶
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
中间件增强框架之-CaptureFramework框架
一、背景 应用服务监控是智能运维系统的重要组成部分。在UAV系统中,中间件增强框架(MOF)探针提供了应用画像及性能数据收集等功能,其中数据收集功能主要采集四类数据:实时数据、画像数据、调用链接数据生成以及线程数据分析数据。为实现实时数据采集,UAVStack设计了CaptureFramework框架,提供统一的数据抓取行为和生成抓取结果能力。 二、CaptureFramework运行原理 2.1 关键技术说明 JavaAssist Monitor捕获体系 precap/docap 2.2 架构说明 捕获点:支持Tomcat、MSCP、Springboot、Jetty埋点。 UAVServer单例:作为统一的捕获入口点,提供了同步和异步方法。 StandardMonitor:实现了Monitor接口,是实时数据抓取实现类,提供了doCapture方法,负责抓取行为和生成抓取结果。 MonitorElemCapHandler:不同的抓取逻辑和抓取点的共同接口实现不同的埋点逻辑,提供了抓取行为的方法preCap与doCap以及生成抓取结果的方法preStore。 StandardMonit...
- 下一篇
免运维,低成本,应用上云新模式 | 阿里云轻量级分布式应用服务 SAE 邀您公测
您是否遇到过: 资源利用率低,多数服务器CPU平均利用率在10%以下,用户需为大量闲置资源买单。 感知 IaaS 购买和集群运维,人员技能要求高,运维效率低。 想拥抱 Kubernetes、微服务架构来解决业务痛点,但学习曲线陡。 阿里云轻量级分布式应用服务SAE给出了这些难题的解决方案。 公测地址:点击这里 (公测期间,创建应用全部免费,每个账户体验的额度上限为 16Core 32GiB) 轻量级分布式应用服务(Serverless App Engine,简称 SAE)是面向应用的 Serverless PaaS 平台,帮助 PaaS 层用户免运维 IaaS,按需使用,按量计费,实现低门槛微服务应用上云,有效解决成本及效率问题。支持 Spring Cloud、Dubbo和HSF 等流行的开发框架,真正实现了 Serverless 架构和微服务
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS8编译安装MySQL8.0.19
- Docker安装Oracle12C,快速搭建Oracle学习环境