-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
<feat>(transaction): simplify sending transactions when cross fabric chains #543
<feat>(transaction): simplify sending transactions when cross fabric chains #543
Conversation
赞!方案很完整,完成度很高! |
感觉已经非常接近完美了! 👍 |
Got it :) |
ci还有问题,麻烦看一下 |
正在根据意见修改 |
特性通用化现将fabricDefault属性修改为chainDefault,这样可以为每条链(任意类型)设置一专门的默认账号。 命令修改WeCross-Console中增加setDefaultChainAccount命令(代替setDefaultFabricAccount),用于为一特定链指定默认账户。用法如下。
sendTransaction命令将会优先使用资源所在链的默认账号执行,当未寻找到所在链的默认账号时使用链类型的默认账号执行。当chainName为NULL或null时,执行撤销命令,指定账号的chainDefault属性置空。 listChainAccount在非详细打印条件下只有Fabric账号中打印chainDefault属性(bcos账号通常只有一个就行)。在详细打印时(listAccount -d),所有类型的账号都将打印chainDefault属性。当然也可以通过修改WeCross-Java-SDK自定化更改打印函数。 Test使用WeCross-Demo的混合场景进行调试 在没有找到fabricDefault时使用当前默认Fabric账号发送交易
验证到当chainName没有设置fabricDefault时,sendTransaction将采用当前默认的Fabric账户进行交易发送。 设置fabricDefault并通过fabricDefault进行交易发送
查阅Router 127.0.0.1-8250-25500的日志(我在WeCross中增加了相应的loginfo便于debug)得:
说明此时确实是使用的keyID为2的Fabric账户进行的sendTransaction,同理call也是正常的。 设置已有的fabricDefault
可以看到在设置keyID为1的账户的fabricDefault时,keyID为2的账户的fabricDefault刷掉,始终保持唯一性。 撤销设置chainDefault
可以看到通过设置chainName为NULL(null)可以置空chainDefault属性。 测试其他类型账号能否设置chainDefault
可以看到BCOS2.0的账号也成功设置了默认账号。 |
chainDefault在设置时是没有判断chainDefault是否满足语法规则以及账户类型是否与链类型对应(这一步可以在webpage和weconsole进行检测),WeCross在使用该属性时是会进行检查的。所以当前情况下是允许出现将不存在的chain或者其它类型的chain设置给账户。 现阶段默认用户都是正常的,但是不排除一些奇怪的用户可能会错误地给某一账户设置非对应类型的chainDefault。 已更新代码,使得当这种情况发生时,可以继续正常使用SendTransaction(即不会使用bcos账户对payment.fabric-mychannel链进行访问)。 |
完美了! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
CI failed.
|
I've run gradlew goJF already and push the code again. However, I think ci still cannot succeed as other prs in WeCross-Account-Manager, WeCross-Java-SDK, and WeCross-Consle are not involved. |
feature_fabricDefault
在涉及多个fabric链时,需要频繁切换Fabric的默认账户。需要一种方案来解决该问题。
方案讨论
WeCross-Console本地管理
最理想的情况是在WeCross-Console端建立一个本地的default映射,在调用sendTransaction时将对应的默认账号ID附上。遗憾的是WeCross在执行sendTransaction时是向WeCross-Account-Manager请求的默认账号用于发送交易信息,采用该方案需要修改整套WeCross方案。
使用数据库管理fabricDefault数据
该方案是在WeCross-Account-Manager数据库中建立一新的对象fabricDefault,如管理ChainAccount一般管理,因为现在的逻辑是WeCross-Account-Manager每次取UA时会在数据库中遍历寻找它关联的ChainAccount,那么也可以在取UA时遍历寻找它相关的fabricDefault。
该方案的好处是较为安全对现有代码逻辑几乎没有影响,但是需要重新构造一整个fabricDefault的运作方式并附加到UA的维护中,故也没有采用。
ChainAccount增加fabricDefault属性
在现有的ChainAccount基础上,增加一fabricDefault属性,指明该ChainAccount是哪一个fabric链的默认账户,如果不是默认账户则该项置空。该方案实现简单同时符合现在的WeCross与WeCross-Account-Manager的运作逻辑。选取该方案。
实现
在WeCross-Console中增加setDefaultFabricAccount指令,命令使用方法如下:
其中payment.fabric-mychannel为chainName,1为账户的keyID。仿照setDefaultAccount写底层逻辑,在WeCross-Java-SDK中增加setDefaultFabricAccount的调用函数,以及修改listAccount的打印方式来显示fabric账户的fabricDefault属性。
在WeCross中增加/auth/setDefaultFabricAccount的路由,同时修改UA的构造方法,更改asynSendTransaction和asynCall中获取默认账户的方法。
在WeCross-Account-Manager中为ChainAccount增加fabricDefault属性,修改相应的对象构造方法以及数据库更新方法。
Consideration
由于修改了fabric链的sendTransaction与call的默认账户获取方式,不知道对WeCrossHub、HTLC、XA相关有没有影响(目测感觉没有)。
Future
Want
需要WeCross的跨多条Fabric链的一键部署脚本,否则开发测试过于困难。
Test
使用WeCross-Demo的混合场景进行调试(实在是没找到两条链的fabric演示场景,所以在确认方案是否有效时是通过查日志实现的,太麻烦了)
在没有找到fabricDefault时使用当前默认Fabric账号发送交易
验证到当chainName没有设置fabricDefault时,sendTransaction将采用当前默认的Fabric账户进行交易发送。
设置fabricDefault并通过fabricDefault进行交易发送
查阅Router 127.0.0.1-8250-25500的日志(我在WeCross中增加了相应的loginfo便于debug)得:
说明此时确实是使用的keyID为2的Fabric账户进行的sendTransaction,同理call也是正常的。
设置已有的fabricDefault
可以看到在设置keyID为1的账户的fabricDefault时,keyID为2的账户的fabricDefault刷掉,始终保持唯一性。