虚拟机上程序跑不动,求优化程序

benpao002 2018-03-15 01:50:26
测试数据如下
CUST_ID TYPE C_type R F M
1000022035 FINC 1000022035FINC 19 5 2619.5
1000007371 FUND 1000007371FUND 65 33 7857.63
1000010935 ABCD 1000010935ABCD 111 2 13393.88
1000009878 FUND 1000009878FUND 101 16 22776.07
1000086999 ABCD 1000086999ABCD 200 18 18868.9
1000015333 FINC 1000015333FINC 157 1 23044.26
1000000176 FUND 1000000176FUND 38 29 1541.59
1000036287 INNO 1000036287INNO 121 15 7601.34
1000018585 FINC 1000018585FINC 46 19 5974
1000013007 FINC 1000013007FINC 14 2 7790.95
1000044588 ABCD 1000044588ABCD 131 16 4872.83
1000020565 ABCD 1000020565ABCD 60 3 6516.62
1000086543 ABCD 1000086543ABCD 51 28 7688.32
1000082652 FINC 1000082652FINC 116 23 6672.82
1000037259 ABCD 1000037259ABCD 151 9 8767.72
1000078492 FINC 1000078492FINC 35 3 4613.98
1000053089 INNO 1000053089INNO 64 4 8000.12
1000023373 ABCD 1000023373ABCD 80 20 13348.91
1000016112 FUND 1000016112FUND 97 41 6958.97
1000070555 FINC 1000070555FINC 185 9 15088.13
1000012595 FINC 1000012595FINC 61 3 13111.62
1000035257 INNO 1000035257INNO 29 5 13612.72
1000084843 INNO 1000084843INNO 12 11 9202.32
1000026758 FINC 1000026758FINC 116 6 6148.55
1000035458 INNO 1000035458INNO 42 12 4076.75
1000056708 FUND 1000056708FUND 78 10 890.79
1000044768 FUND 1000044768FUND 102 24 11968.57
1000025022 FINC 1000025022FINC 119 19 21549.5
1000017543 ABCD 1000017543ABCD 64 10 8490.13
1000030079 INNO 1000030079INNO 76 26 5553.97
1000002432 FINC 1000002432FINC 133 8 6924.37
1000088290 ABCD 1000088290ABCD 22 39 4100.83
1000019673 FINC 1000019673FINC 34 20 10319.45
1000050817 FINC 1000050817FINC 131 26 10838.23
1000014588 INNO 1000014588INNO 87 26 8142.7
1000006726 FUND 1000006726FUND 94 12 155.42
1000073635 FINC 1000073635FINC 80 19 1540.57
1000039912 INNO 1000039912INNO 97 10 7195.78
1000044160 INNO 1000044160INNO 34 47 5872.89
1000006676 ABCD 1000006676ABCD 34 8 8702.41
1000014460 ABCD 1000014460ABCD 14 17 4565.58
1000019006 FINC 1000019006FINC 80 3 3677.92
1000007343 FINC 1000007343FINC 170 1 3289.29
1000069748 FUND 1000069748FUND 242 29 3811.78
1000001022 ABCD 1000001022ABCD 28 19 4045.45
1000038481 FUND 1000038481FUND 141 13 7175.09
1000016176 FUND 1000016176FUND 48 6 3454.74
1000041960 INNO 1000041960INNO 41 20 1435.24
1000028655 FUND 1000028655FUND 37 26 661.49
1000022715 ABCD 1000022715ABCD 176 2 7609.48
1000016068 FUND 1000016068FUND 57 2 3717.74
1000031305 FUND 1000031305FUND 125 2 12615.62
1000059113 FINC 1000059113FINC 49 18 6866.41
1000011743 ABCD 1000011743ABCD 23 21 9016.63
1000068949 INNO 1000068949INNO 11 16 7340.29
1000026857 ABCD 1000026857ABCD 127 29 14750.69
1000083960 FUND 1000083960FUND 20 9 9242.62
1000066538 ABCD 1000066538ABCD 80 6 24088.42
1000033781 FINC 1000033781FINC 124 35 6261.55
1000046597 ABCD 1000046597ABCD 41 3 34.07
1000085541 INNO 1000085541INNO 40 28 13049.87
1000080339 ABCD 1000080339ABCD 4 18 1045.7
1000060413 ABCD 1000060413ABCD 3 23 8093.88
1000014331 INNO 1000014331INNO 77 26 5146.14
1000024704 FINC 1000024704FINC 208 23 22934.47
1000002660 ABCD 1000002660ABCD 177 22 8430.75
1000020067 ABCD 1000020067ABCD 60 38 14854.19
1000002904 INNO 1000002904INNO 169 16 5089.62
1000078694 ABCD 1000078694ABCD 131 4 4951.14
1000081939 FUND 1000081939FUND 184 7 10523.84
1000021367 FINC 1000021367FINC 97 2 4547.06
1000048539 FUND 1000048539FUND 21 31 4008.51
1000003869 FUND 1000003869FUND 152 2 7533.7
1000051597 ABCD 1000051597ABCD 53 22 5775.29
1000078004 FINC 1000078004FINC 70 2 10829.21
1000001687 FINC 1000001687FINC 36 7 7114.01
1000020738 FUND 1000020738FUND 33 5 14569.43
1000034645 ABCD 1000034645ABCD 76 8 4387.82
1000050908 ABCD 1000050908ABCD 17 21 19406.77
1000085923 ABCD 1000085923ABCD 70 12 11740.37
1000047202 FINC 1000047202FINC 94 23 1516.91
1000063370 FUND 1000063370FUND 117 7 8538.33
1000071163 FUND 1000071163FUND 28 27 12087.62
1000072458 INNO 1000072458INNO 65 15 10802.66
1000074811 INNO 1000074811INNO 114 2 5482.55
1000008267 INNO 1000008267INNO 83 2 95.87
1000079342 INNO 1000079342INNO 51 38 9612.83
1000086488 INNO 1000086488INNO 100 35 931.49
1000065092 FUND 1000065092FUND 22 8 498.86
1000052032 FUND 1000052032FUND 27 34 1424.12
1000063197 INNO 1000063197INNO 47 23 15487.59
1000072519 ABCD 1000072519ABCD 7 10 19369.02
1000044220 ABCD 1000044220ABCD 21 18 7966.25
1000010107 ABCD 1000010107ABCD 185 25 630.34
1000053089 ABCD 1000053089ABCD 51 11 1577.04
1000088058 FUND 1000088058FUND 65 4 12093.7
1000045471 FINC 1000045471FINC 172 20 3245.27
1000017361 FUND 1000017361FUND 150 39 17702.66
1000085040 INNO 1000085040INNO 44 28 1660.34
1000003838 ABCD 1000003838ABCD 32 16 3212.38
1000085520 FUND 1000085520FUND 160 9 5185.38
1000068164 FUND 1000068164FUND 95 2 14109.58
1000008129 ABCD 1000008129ABCD 158 35 5038.13
1000066291 ABCD 1000066291ABCD 13 18 7453.82
1000060129 FINC 1000060129FINC 66 26 2521.97
1000026887 FINC 1000026887FINC 47 42 7021.99
1000012395 FINC 1000012395FINC 295 34 12300.29
1000044326 ABCD 1000044326ABCD 235 26 1570.38
1000030313 ABCD 1000030313ABCD 113 18 1733.62
1000021816 ABCD 1000021816ABCD 28 20 14689.03
1000024800 FUND 1000024800FUND 97 30 2508.29
1000030606 ABCD 1000030606ABCD 122 16 3146.24
1000073010 FUND 1000073010FUND 119 9 7175.81
1000072495 ABCD 1000072495ABCD 151 16 15799.19
1000020660 FUND 1000020660FUND 30 1 10839.49
1000004196 INNO 1000004196INNO 105 24 16336.35
1000033440 FUND 1000033440FUND 112 2 8312.03
1000002318 FINC 1000002318FINC 32 5 11336.63
1000079575 ABCD 1000079575ABCD 26 4 83.06
1000028547 FINC 1000028547FINC 69 27 25111.19
1000029319 FUND 1000029319FUND 91 7 8671.93
1000010170 ABCD 1000010170ABCD 112 20 19899
1000080909 FUND 1000080909FUND 160 17 13788.88
1000086787 ABCD 1000086787ABCD 107 9 14423.17
1000069147 INNO 1000069147INNO 83 7 13254.72
1000034824 FINC 1000034824FINC 20 21 1276.3
1000031687 FUND 1000031687FUND 24 20 884.41
1000048212 ABCD 1000048212ABCD 98 25 13636.32
1000019325 FINC 1000019325FINC 14 22 21255.6
1000085412 FINC 1000085412FINC 22 12 20566.53
1000034075 FUND 1000034075FUND 19 9 5614.43
1000039821 ABCD 1000039821ABCD 91 5 18842.29
1000010268 FUND 1000010268FUND 79 6 14667.01
1000009500 FINC 1000009500FINC 20 17 5369.72
1000027326 INNO 1000027326INNO 22 19 6526.2
1000051411 ABCD 1000051411ABCD 14 2 4461.84
1000084959 INNO 1000084959INNO 105 37 188.49
1000049201 ABCD 1000049201ABCD 113 5 12294.91
1000008491 FUND 1000008491FUND 11 10 14253.84
1000016962 INNO 1000016962INNO 104 15 1869.37
1000078121 INNO 1000078121INNO 223 25 7094.77
1000081718 ABCD 1000081718ABCD 26 12 4548.16
1000028174 FINC 1000028174FINC 50 42 4758.48
1000004954 FINC 1000004954FINC 145 29 9476.13
1000036116 INNO 1000036116INNO 9 8 4864.45
1000039905 INNO 1000039905INNO 194 34 21570.23
1000027612 FINC 1000027612FINC 165 38 12390.87
1000070955 FUND 1000070955FUND 135 8 24209.79
1000036775 ABCD 1000036775ABCD 97 12 1717.05
1000073378 FINC 1000073378FINC 31 26 8191.49
1000016869 ABCD 1000016869ABCD 69 19 2428.01
1000028992 ABCD 1000028992ABCD 57 20 12016.48
1000051931 FUND 1000051931FUND 171 7 932.72
1000000419 INNO 1000000419INNO 110 15 10684.28
1000077185 INNO 1000077185INNO 31 5 1660.17
1000015481 INNO 1000015481INNO 25 16 2448.91
1000034551 ABCD 1000034551ABCD 159 51 1486.68
1000001895 ABCD 1000001895ABCD 50 2 9937.29
1000031626 ABCD 1000031626ABCD 25 33 1478.46
1000021670 FINC 1000021670FINC 200 33 5687.6
1000074136 INNO 1000074136INNO 38 44 5094.93
1000082912 ABCD 1000082912ABCD 11 20 6014.07
1000006801 INNO 1000006801INNO 9 7 15781.43
1000038944 FUND 1000038944FUND 44 25 14686.39
1000021194 FINC 1000021194FINC 20 6 12898.48
1000059740 FINC 1000059740FINC 12 23 7883.53
1000034623 FINC 1000034623FINC 16 13 11356.11
1000077555 FINC 1000077555FINC 104 13 8586.82
1000016194 ABCD 1000016194ABCD 40 3 2472.48
1000062170 FUND 1000062170FUND 19 3 1775.35
1000056224 FINC 1000056224FINC 95 10 12450.4
1000007131 INNO 1000007131INNO 129 16 8226.39
1000060947 INNO 1000060947INNO 24 12 2418.66
1000009212 FINC 1000009212FINC 26 17 637.64
1000053014 INNO 1000053014INNO 70 1 9854.85
1000027868 FINC 1000027868FINC 27 18 3806.81
1000041435 INNO 1000041435INNO 98 9 5069.59
1000083923 FUND 1000083923FUND 30 22 1466.57
1000012331 INNO 1000012331INNO 10 9 8676.51
1000064166 INNO 1000064166INNO 156 8 1598.3

drop table if exists crfm1;
create table crfm1
(
cust_id varchar(20),
type varchar(20),
coun int(10),
c_type varchar(50),
r int(10),
f int(10),
m decimal(20,2)
);
INSERT INTO crfm1(cust_id,type,coun,c_type,r,f,m)
select cust_id,type,count(c_type),c_type,r,f,m from cssj group by c_type;

drop table if exists crfm2;
create table crfm2
(
cust_id varchar(20),
r int(10),
f int(10),
m decimal(20,2)
);
INSERT INTO crfm2(cust_id,r,f,m)
select cust_id,sum(r),sum(f),sum(m) from crfm1 group by cust_id;

drop table if exists crfm3;
create table crfm3
(
cust_id varchar(20),
r int(10),
r1 int(10),
f int(10),
f1 int(10),
m decimal(20,2),
m1 decimal(20,2)
);
INSERT INTO crfm3(cust_id,r,r1,f,f1,m,m1)
select a.cust_id,r,a.r1,f,b.f1,m,c.m1
from
(select * from crfm2)d,
(select cust_id,
(case
when r<=30 then 5
when r>30 and r<=60 then 4
when r>60 and r<=180 then 3
when r>180 and r<=360 then 2
when r>360 then 1
end)r1 from crfm2)a,
(select cust_id,
(case
when f<=12 then 1
when f>12 and f<=22 then 2
when f>22 and f<=33 then 3
when f>33 and f<=48 then 4
when f>48 then 5
end)f1 from crfm2)b,
(select cust_id,
(
case
when m<=5578.53 then 1
when m>5578.53 and m<=10509.02 then 2
when m>10509.02 and m<=15852.05 then 3
when m>15852.05 and m<=23399.88 then 4
when m>23399.88 then 5
end)m1 from crfm2)c
where a.cust_id=b.cust_id and a.cust_id=c.cust_id and a.cust_id=d.cust_id;
如上所述,上面是测试数据,下面是代码,这个代码在我个人电脑上跑完全没问题,但是在虚拟机上进行运行,crfm3 insert在数据量比较大的情况下比方说200000条的情况下完全跑不动,20000条勉强能跑,急求改良程序解决办法,谢谢!
...全文
644 5 打赏 收藏 转发到动态 举报
写回复
用AI写文章
5 条回复
切换为时间正序
请发表友善的回复…
发表回复
moshangdanqing 2018-03-20
  • 打赏
  • 举报
回复
在cust_id上添加字段
OwenZeng_DBA 2018-03-15
  • 打赏
  • 举报
回复
数据库慢和很多方面都有关系,虚拟机只是其中一项
吉普赛的歌 2018-03-15
  • 打赏
  • 举报
回复
SELECT cust_id,
       r,
       r1,
       f,
       f1,
       m,
       m1
FROM   crfm2
		,r
       ,CASE 
            WHEN r <= 30 THEN 5
            WHEN r > 30 AND r <= 60 THEN 4 
            WHEN r > 60 AND r <= 180 THEN 3 
            WHEN r > 180 AND r <= 360 THEN 2 
            WHEN r > 360 THEN 1 
        END AS r1
        ,f
        ,CASE 
            WHEN f <= 12 THEN 1 
            WHEN f > 12 AND f <= 22 THEN 2 
            WHEN f > 22 AND f <= 33 THEN 3 
            WHEN f > 33 AND f <= 48 THEN 4  WHEN f > 48 THEN 5 
            END 
        AS f1
        ,
        CASE 
            WHEN m <= 5578.53 THEN 1
            WHEN m > 5578.53 AND m <= 10509.02 THEN 2 
            WHEN m > 10509.02 AND m <= 15852.05 THEN 3 
            WHEN m > 15852.05   AND m <= 23399.88 THEN 4 
            WHEN m > 23399.88 THEN 5 
            END AS m1
这样能不能快点?
benpao002 2018-03-15
  • 打赏
  • 举报
回复
引用 1 楼 ap0405140 的回复:
在crfm2表的cust_id字段上应有索引.
嗯,这个想到了,呆会去试下,可否使用临时表来改良程序,如果可以,该怎么写呢
唐诗三百首 2018-03-15
  • 打赏
  • 举报
回复
在crfm2表的cust_id字段上应有索引.
智能合约虚拟机赋予了区块链运行去中心化应用(Dapp)的能力。它让区块链演化为“操作系统”,孕育出繁荣的Dapp生态。一款优秀的VM不仅仅是要完成确定、高效、安全地执行合约字节码的功能,它应该足够通用,能最大化节省开发者的成本,甚至能形成独立的开发者生态。从架构上来说,VM为智能合约提供计算资源和运行容器,区块链的共识、执行模块与VM是完全解耦的。在区块链2.0项目中,我们看到大部分项目将VM作为区块链项目的一个子模块,一同编译进二进制中;Fabric更进一步,链码被编译成独立的程序,运行于独立的docker容器中,通过grpc与节点交互。如此,可将数据与逻辑彻底分离;在未来,VM可能以硬件的形式安装在“矿机”中,通过更底层的如PCIe接口与区块链进行通信。业界的Nervos CKB使用RISC-V实现VM,为演化成硬件模块做准备。架构设计验证层验证层会对合约字节码及传参进行一些验证,包含ABI验证,环境检查与版本检查三个环节。ABI验证:利用合约ABI对用户发送的合约调用及参数进行校验。环境检查:检查虚拟机执行环境是否符合预期检查Config字段。字节码是否合法。exports是否包含apply与memory,以及类型是否正确;是否包含start(被禁用);是否包含import,import的模块是否合法。解释器模块是否ready。版本检查:检查合约版本,选择对应版本的解释器。注入层注入层主要对合约字节码注入一些必要的代码,以及构建相应的执行上下文。Gas MeteringGas metering是用于统计每一个操作所须花费的Gas。原理非常简单:实现Env_api方法useGas。将wasm字节码恢复成易于解析的格式化文本(如JSON)。将useGas注入到格式化文本中将格式化文本重新恢复成wasm字节码。这里有一个值得考虑的问题:**Gas Metering能否放到编译期去做?**在编译器做Gas metering注入的好处是只须要注入一次,节省了执行时的开销。但这样的弊端也很明显:Gas Table本属于区块链协议的一部分,但却被放到合约编译器中,恶意用户只须要更改编译器的Gas Table即可完成作恶,作恶成本大大降低。若Gas Table需要修改,无法再对已部署的旧合约更新Gas Metering,导致新老合约的Gas收费标准不一致。在每次执行时进行一次Gas Metering注入,虽然牺牲了一些执行效率,但换来了Gas灵活变更的特性,这对于不断调整、迭代的公链项目是至关重要的。一种更好的方案,是将Gas Table以合约形式部署,无须硬分叉便可更改Gas Table的参数。Env API 注入Env_api是区块链提供给合约层用于与区块链进行交互的接口。注入原理如下:合约字节码(wast)中包含形如(import env getAddress (func ...))的代码段。意为从env模块中导入getAddress函数。env模块从哪来呢?由虚拟机利用解释器的API构建原生模块,并实现预先设计的Env_api。这里的Env_api都须要用原生语言实现。利用解释器的moduleResolver在执行代码前注入。经以太坊基金会Go-team的gary推荐,这里隆重介绍下EVMC这个项目。它提供了一套虚拟机和客户端之间的通用交互接口。不同的VM只需要实现这些接口,即可为以太坊客户端提供交互功能。如此将客户端与虚拟机实现相互分离,更能够根据实际情况灵活切换底层虚拟机实现。上下文构建我们还需要给合约执行构建合理的上下文环境,提供必要的内部模块和数据以供合约使用,包括:区块链账本实例,提供区块、交易等信息的调用接口。状态数据库实例,提供状态数据的增删改查的调用接口。当前Transaction与Action的相关数据。当前区块高度和区块时间。执行层执行层是虚拟机的核心模块,负责执行合约字节码并返回结果。它必须具备以下几个特性:确定性:即相同入参和上下文,无论在什么设备上运行,何时运行,运行几次,都必须获得相同结果。高效执行:虚拟机的执行时间不大于共识算法给于交易执行的最大时间。停机与回滚:须要有相应停机机制。在执行失败时须要对本次执行涉及的所有状态变更进行回滚。沙箱环境:即保证合约与合约之间、合约与宿主系统之间的资源隔离。能够防备恶意和故障合约的不良影响。Apply执行合约字节码,实际是调用合约代码中的apply函数。合约上下文,包括用户指定调用的合约方法名和对应入参,通过Env_api在实际apply实现中获取,最终调用相应的合约方法。栗子详见系列第二篇。Memory合约除了应导出apply函数外,还须要导出memory对象。memory对象是wasm编译器在合约编译时自动注入,通常会开辟一页内存(64KB) (memory $0 1)。解释器会初始化一个线性字节数组作为内存供wasm使用,wasm与区块链数据交互是依靠内存共享的形式,通过该字节数组进行传递。(这也是为何在Env_api设计里,很多数值的传参是offset与length的组合)Wasm的内存数组是按照| static memory | dynamic memory |的次序划分,static memory中存放编译期的字符串或数组,dynamic memory用于运行期的数据存储,并且可以动态扩容。为了防止dynamic memory无限制地扩容,需要有合理的收费机制与内存分配上限。AssemblyScript提供了一个额外的位于static memory之前的预留空间,称为reserved memory。这使得我们在运行期可以将一些变长数据(如字符串,数组等)以Global的形式导入wasm。这样wasm无须调用Env_api即可直接使用上下文的变量,如发送方、接收方、合约地址、当前调用的合约方法名等。状态存储对VM最本质的需是对状态存储的需,这种存储是达成共识的、不可逆的,从而实现了去中心化应用中数据的信任存储。Ethereum1出现的状态爆炸问题给我们敲响了警钟——只收取每一次读写操作的费用,而不收取占用存储的费用,是不合理的。如果不对占用存储收费,则用户可以无限制地占用区块链的稀缺存储资源;且由于没有好的数据清理机制,区块链的状态就会不断增长,即所谓“爆炸”。状态存储付费是很自然想到的方案。如何设计合理的状态存储付费方案,有两个底层逻辑需要考虑:用户应当为占用链上的稀缺存储资源付出成本。这里的成本是广义的,可以是代币价值、机会成本与承担额外风险等形式。状态存储的使用属性最大化,投资属性最小化。须要避免出现用户大量囤积存储资源,提高资源利用率。EOS使用【RAM】来解决状态收费的问题。开发者须要使用代币向系统合约购买RAM,存储状态数据须要消耗对应大小的RAM资源,当数据删除时RAM资源也会相应释放,并且可以卖回给系统拿回代币。但开发者须要承担RAM和代币价值波动风险。如何对RAM定价呢?EOS创新性地引入了Bancor算法对RAM进行模拟市场定价。Bancor算法有两个特点:数字货币价格取决于存储金金额和代币流通量,真实模拟了市场供需关系;人机交易,无须对手盘,这使得“巨鲸”可轻易做多或做空,导致价格波动剧烈。也正因为上面两个特性,EOS主网刚上线时,出现了大量RAM资源被囤积,RAM价格被瞬间拉至高位,又在随后的一周内快速下降,造成了“割开发者韭菜”的情况。V神在2018年曾提出过使用【状态租金】来解决状态爆炸问题。状态租金很像当前云计算服务的商业模式,用户不仅花费购买占用空间大小,还须购买占用时间。对于状态租金方案的具体设计,我们仍然须要考虑以下几个问题:用户体验:当状态出租时间快到期时,如何提醒用户续费?时间到期后状态数据是否立马清除?不同级别的数据是否有区别的对待?(云服务厂商都会提供到期后的赎回期,以防止关键数据被意外删除)支付对象:哪些数据需要支付租金?除了合约的状态数据必然要支付租金以外,账户本身的元数据(balance, nonce等)是否也要付租金?如果需要,时间到期后清零,势必损害用户的资金安全(与区块链保护数字资产的理念相背),同时nonce为0后可能会遭受重放攻击。如果不需要,仍然无法抑制因新账户的创建而产生的状态爆炸问题。定价:链上存储资源的稀缺程度,与区块链的生态价值及当下的市场需密切相关。如何建立一个合理定价模型便是个非常重要的问题。Ethereum Research中有大神对状态租金的方案进行了细化,引入了激励机制用于租赁过期的发现和确认,并且允许在状态数据删除后申请恢复。Nervos CKB结合了状态买卖和状态租金的长处,利用原生代币代表占用全局状态的权利,且汇率恒定,即1 CKB代表1 Bytes的存储空间。同时巧妙地利用【二级发行】机制为代币持有者(存储空间占有者)设置了【通胀税】,以作为支付给矿工的状态租金。靠通胀收取租金的方式既保留了RAM方案的买断存储空间的使用模式,解决了上面所提到的用户体验的问题,又将定价转移到了通胀部分对应的法币价值,完全由二级市场进行价值发现。但这使得状态空间的上限严格等同于当前代币流通量,在初期可能会限制生态的发展。合约安全我们在第一篇中有提到,合约安全分为编译期安全和执行期安全。本篇主要阐述执行期安全的设计思路。执行期安全也成为运行期安全,主要由VM针对以下两方面提供保障:数据安全:不能随意篡改其他用户或其他合约的状态数据。资源安全:CPU、内存、硬盘资源的分配与回收。数据安全加密数字资产真正实现了人类梦寐以的“私有财产神圣不可侵犯”,它象征着真正的自由。为了捍卫这份“自由”,数据安全是重中之重。VM需要为以下两个方面提供安全保障:用户数据的安全,即利用密码学算法判断是否有修改状态数据的权限。合约状态数据的隔离,即任何合约都不能直接修改其他合约的状态数据,即使该用户拥有权限。第一个维度很好理解,合约会提供根据用户地址和交易签名进行身份权限审查的功能(甚至可提供基于多密钥对的权限管理),以判断本次合约调用是否有权限修改相应的数据。这也是“私有财产神圣不可侵犯”的根源。第二个维度需要特别解释一下。这里的不能直接修改其他合约的状态数据,是指不能在合约A的方法中直接修改合约B的数据。为什么?因为这会导致状态变更无法追溯,带来不确定性。我们知道,区块链环境中只能通过交易(Transaction)来触发状态变更,交易本身就是状态变更的日志。若允许在合约A中直接修改合约B的状态数据,则这次修改是并未生成相关日志的,使得状态修改无法追溯,与区块链“可追溯”的特性相违背。以太坊中跨合约调用也是没有保留日志的。笔者认为这是因为以太坊合约是不可升级的,一旦部署后地址和代码都是不可变更的,因此可结合交易和代码具体片段来追踪状态变更记录。但以太坊并没有提供相关的索引,这导致对状态修改的记录追踪基本不可能,因此我认为这是一个设计上的重大缺陷。在EOS中,我们看到跨合约调用是生成了新的action,并被加入到原action列表中,在链上保留了状态修改的日志。能否利用静态代码分析的方式确定跨合约的对方地址和相关合约方法,从而追溯到状态变更的细节?当然是可行的,但如果有多层调用(合约A -> 合约B -> ... -> 合约Z),这种方案显然开销是非常大的。尽管以太坊提供了tracer,可以在执行交易的过程中追踪跨合约调用的对象,但如果我想查找导致合约X某状态变更的所有历史操作,上述方案必须遍历并模拟执行所有的历史交易,显然是不可取的。我们认为,跨合约交易正确的做法,是通过内联交易的形式调用合约B的方法从而间接修改合约B数据。即生成一个新的交易来触发目标合约的状态变更。该交易也会应放入区块中,视为由原交易生成的日志。这样可为状态变更保留操作记录,也符合“可追溯”的特征。资源安全智能合约通常运行在由虚拟机提供的沙箱环境,我们需要对其能够使用的资源进行适度的把控。这些资源包括三类:CPU、内存、硬盘。下面我们以QA的形式对涉及到的问题进行解答——CPU资源Q1: 合约运行最大能占用多少个进程,多少个线程?一个;一个或多个。Q2: 是否允许合约内开辟新线程?不允许。合约不应有操作系统级别的调用,而应由虚拟机层来确定性地分配CPU资源(线程数)。Q3:多线程下如何保证线程安全?多线程下,不应通过加锁来保证线程安全,原因是加锁无法保证执行顺序,带来不确定性。正确的做法是在执行前通过静态分析、注解等手段对合约调用进行归类。互斥资源的调用顺序遵循交易发送的顺序;非互斥资源的合约调用可以并行执行。Q4: 如何控制执行时间?利用Gas机制控制合约执行时间(在本系列第一篇已提到),避免过度占用CPU时间。Q5: 如何捕捉错误与处理?合约执行的错误不应导致虚拟机的进程终止,虚拟机应当提供错误捕获和处理的机制。常规的做法时合约运行时的错误以error的形式抛出,虚拟机层捕获后做失败处理,包括终止交易执行、状态回滚、资源回收等。内存资源Q1:合约运行最大能占用多少内存?节点能分配多大的内存给虚拟机,是由矿工决定。这本质上经济学问题:扩大内存分配无疑会增加成本,而这部分提升的执行效率能为矿工带来多少收益。若可用内存过少,部分交易执行失败,可能导致分叉;若可用内存过多,又会造成资源浪费,降低矿工收益。Q2: 内存能否动态扩张?可以,但须要付费。为了防止内存无限制扩张,虚拟机还应对合约的内存占用设置上限。Q3: 如何避免内存泄漏?不应交由合约开发者控制内存回收,虚拟机应当实现GC机制。Q4: 如何避免内存溢出?Wasm虚拟机中内存实则为字节数组,本身带有边界控制,能有效防止内存溢出。磁盘资源Q1: 单个合约最多能够存储多少数据?这也是经济学问题,应该设置合理的硬盘占用计费。Q2: 能否修改其他合约的持久化数据?不能直接修改,因为这会影响到【数据安全】章节中提到的确定性。虚拟机为合约创建的上下文环境中,包含相互隔离的数据空间。可以通过创建新的上下文环境进行数据修改,这样的操作视为一次新的合约调用(保留日志)。Q3: 如何防止未知的数据丢失(如磁盘损毁)?当发生数据丢失时,节点执行合约会得到不同的状态结果,导致区块被认定为非法,区块链无法延长。这里需要区块链系统具备状态一致性的检测机制,在解决硬盘故障后采用同步主链块并重放交易的方式进行恢复。系统合约系统合约是指区块链系统在启动时预先部署的,可升级、可治理的合约,提供如权限控制、资源租赁、代币质押等基础服务。系统合约通常有以下三个特点:公开透明,无暗箱操作。可通过Env_api被用户合约调用。合约通过治理进行代码变更,无须硬分叉。系统合约可采用普通合约的实现方式,并在系统预定的合约地址部署。未来优化方向智能合约的并行执行合约并行执行是提升智能合约执行效率的一大思路。这里的并行执行并不是指单个合约方法内部的并行,而是合约间的并行。实现合约并行执行,我们需要考虑两个重要的问题:如何检测本次合约执行所访问的资源对象?如读写状态数据、读取账户余额等互斥操作。如何做合约执行的合理调度?即哪些合约能够并行执行,哪些必须串行?一种容易想到的思路是这样的:通过静态代码分析检测出合约方法可能访问到的资源,对会访问相同资源的合约调用归为同一个组。每个组的执行可以并行化,组内执行则串行化(根据交易发送顺序)。然而,实际设计时需要考虑的因素就复杂很多:如何设计一个完备的算法,准确地检测合约方法可能访问到的资源(包括跨合约调用中的资源访问)?如何设计一个高效的调度算法,将合约调用准确分组?合约并行执行后所带来的性能提升,是否能够追回以上两个算法所带来的开销?预言机预言机是智能合约获取链外数据的桥梁。这些数据通常由第三方可信数据源提供,如天气数据、赛事数据、数字货币价格等。在传统的互联网应用中,我们可以简单地通过HTTP API获取到这些数据。但在智能合约却不行,原因是HTTP调用通常是异步的,时间不可预估且不具备确定性。因此,需要一个专门的基础设施来为智能合约提供这些链外数据。预言机的设计原则中需要考虑三个要点:获取链外数据并保证数据的真实可用。以确定性、同步的方式被智能合约调用获取。预言机网络本身的安全性和可用性。隐私保护密码学的研究推动了隐私领域的创新。隐私研究主要涉及零知识、多方计算、全同态加密等领域。多方计算 MPC 允许一组人基于他们的输入进行联合计算,而不需要每个人显示其输入值。 例如,Alice 和 Bob 想要知道谁拥有的比特币更多,那么在不需要他们披露自己拥有多少比特币的情况下就能达到这个目的。遗憾的是,目前多方计算的局限性在于它在实践中使用效率极低。全同态加密 (Fully homomorphic encryption) 则允许人们在加密的数据上计算。几十年来,这一直是密码学领域中的一个未解决的问题,直到 2009 年,斯坦福大学博士生克雷格·詹特利 Craig Gentry 使用「理想格」构建了第一个全同态加密方案。如果 Bob 想在 Alice 的数据上执行任意计算,比如训练机器学习模型,同时不必要 Alice 显示明文数据,理想格加密方案就能派上用场。全同态加密和多方计算一样,目前仍然基本上停留在理论阶段,在实践中的使用效率太低。 

27,579

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 应用实例
社区管理员
  • 应用实例社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧