以太坊Devcon大会精选！十大关键技术全解析，将彻底改变Web3？

交易签名验证：DeFi合约需要为合约中的关键方法加上Forta的签章参数

交易模拟与风险评估：Forta的RPC节点将模拟交易执行过程，通过AI模型评估风险分数。Fora已经实现99%以上的准确度

执行控制：只有风险分数低于门槛值的交易才会获得签名并被放行。

因此这个做法必须由DApp透过Forta提供的RPC发送交易才可以，如果使用公开的RPC则无法取得必要的签章。但这也带来潜在的问题与挑战：

• 升级与整合困难：DeFi协议需要修改合约以整合Forta的系统，这对现有协议的升级是一大挑战，尤其是影响到可组合性，因为其他DeFi协议就无法轻易呼叫自己的合约。
• 交易模拟问题：在链下的环境模拟交易执行的结果可能与实际上链的结果不同，有机会被骇客利用
• 顺序依赖问题：由于L2链上交易的执行顺序是由Sequencer决定，骇客有机会透过交易顺序的不一致性来在模拟时产生正常的结果，拿到签章后上链执行恶意交易

至于如何解决第二个问题，知名交易安全检测公司Blowfish的CTO提到，可以在模拟交易过程检测该交易是否使用了与EVM环境参数相关的逻辑，例如block.timestamp或block.basefee等等，但也无法保证100%判断正确，因此精准的交易模拟仍然是安全领域待解决的难题。

Part5:FuzzTesting

FuzzTesting是一种强大的测试技术，其核心原理是透过大量随机的输入测试智能合约，试图触发意外的逻辑漏洞。这种方法对于捕捉人眼难以察觉的边缘情境（cornercases）尤其有效。

FuzzTesting的原理与限制

Fuzzer的主要作用是持续尝试各种随机输入来检测智能合约是否能满足定义的Invariant（不可变条件）。开发者可以利用这种方法进行黑箱测试，模拟合约的实际使用情境，并验证其逻辑是否能抵抗各种异常操作。

尽管FuzzTesting是捕捉逻辑漏洞的有效工具，但找不到漏洞并不代表合约没有问题。Fuzzer的效果取决于定义的Invariant是否完善，以及随机测试的覆盖范围。

相关范例

以下是三个经典例子，说明如何使用黑箱的FuzzTesting方法来检测系统的正确性：

• 排序演算法测试：原始输入：未排序的数字阵列A。随机调整：对A随机打乱（Shuffle）后再排序，结果应与原始输入排序结果相同。验证：比较两次排序的结果是否一致。
• 最短路径演算法测试：原始输入：图G和两个节点n1与n2。随机调整：从图G移除某条边后，n1到n2的最短路径应该变长或保持不变。验证：比较移除边前后的最短路径。
• 编译器测试：原始输入：程式P。随机调整：在P中加入DeadCode后编译，结果执行的行为应与原始程式一致。验证：比较两次执行结果。

使用Chimera撰写FuzzTest

以下介绍如何使用Chimera框架来整合多种Fuzzer工具（如Echidna、Medusa和Foundry）进行智能合约的Fuzz测试。

案例分析：Vesting合约漏洞

以下是一个简化的Vesting智能合约范例，其目的是实现用户的积分分配与转移，完整程式码在solidity-fuzzing-comparison Repo中的09-vesting。然而，该合约存在一个漏洞：用户可以通过「自我转移」增加自己的积分，进而破坏总积分不变的Invariant。

Vesting.sol合约部分代码：

//usersentitledtoanallocationcantransfertheirpointsto//anotheraddressiftheyhaven'tclaimedfunctiontransferPoints(addressto,uint24points)external{  require(points!=0,Zeropointsinvalid);  AllocationDatamemoryfromAllocation=allocations[msg.sender];  require(fromAllocation.points>=points,Insufficientpoints);  require(!fromAllocation.claimed,Alreadyclaimed);  AllocationDatamemorytoAllocation=allocations[to];  require(!toAllocation.claimed,Alreadyclaimed);  //enforceidenticalvestingperiodsif`to`hasanactivevestingperiod  if(toAllocation.vestingWeeks!=0){    require(fromAllocation.vestingWeeks==toAllocation.vestingWeeks,Vestingmismatch);  }  allocations[msg.sender].points=fromAllocation.points-points;  allocations[to].points=toAllocation.points+points;  //if`to`hadnoactivevestingperiod,copyfrom`from`  if(toAllocation.vestingWeeks==0){    allocations[to].vestingWeeks=fromAllocation.vestingWeeks;  }}

用户可以将自己的积分转移给自己（self-transfer），导致总积分超出限制，破坏合约中「所有用户积分总和应等于总分数」的Invariant。然而就算我们不细看transferPoints的实作，也能透过对其黑箱的Fuzzing来找到问题。

设计Invariant：思考不可变条件

在测试此合约时，可以设计以下两个主要Invariant：

• 初始化阶段：所有用户的积分总和应等于TOTAL_POINTS。
• 执行阶段：在任意操作后，所有用户的积分总和仍应保持不变。

这些Invariant可以被用于多个Fuzzer的测试过程中。

使用Chimera框架进行测试

Chimera是一个功能强大的多工具整合框架，允许开发者一次撰写测试代码，并同时在多个Fuzzer工具上执行。以下是使用Chimera的步骤：

1、安装Chimera：forgeinstallRecon-Fuzz/chimera

2、设定测试环境：建立一个Setup.sol文件来初始化测试合约，并追踪需要检查的状态。

//SPDX-License-Identifier:MITpragmasolidity^0.8.23;import{Vesting}from./Vesting.sol;import{BaseSetup}from@chimera/BaseSetup.sol;abstractcontractSetupisBaseSetup{  Vestingvesting;  functionsetup()internaloverride{    address;    recipients[0]=address(0x1111);    recipients[1]=address(0x2222);    uint24;    points[0]=50_000;    points[1]=50_000;    uint8;    vestingWeeks[0]=10;    vestingWeeks[1]=10;    vesting=newVesting(recipients,points,vestingWeeks);  }}

3、实现Invariant：定义检查条件，例如所有用户的积分总和应等于总积分。

functionproperty_users_points_sum_eq_total_points()publicviewreturns(boolresult){  uint24totalPoints;  //sumupalluserpoints  for(uint256i;i<recipients.length;i++){    (uint24points,,)=vesting.allocations(recipients[i]);    totalPoints+=points;  }  //trueifinvariantheld,falseotherwise  if(totalPoints==TOTAL_POINTS)result=true;}

4、定义如何测试目标函数：指定transferPoints参数需满足的条件，避免因错误参数导致的Revert

functionhandler_transferPoints(uint256fromIndex,uint256toIndex,uint24points)external{  fromIndex=bound(fromIndex,0,recipients.length-1);  toIndex=bound(toIndex,0,recipients.length-1);  addressfrom=recipients[fromIndex];  addressto=recipients[toIndex];  points=uint24(bound(points,1,vesting.allocations(from).points));  vesting.transferPoints(to,points);}

5、执行FuzzTesting

forgetest--match-contractVestingCryticToFoundry

可以看到Fuzzer在短时间内就找到了打破不变量的方法

修复漏洞

漏洞的解法是避免自我转移：

functiontransferPoints(addressto,uint24points)external{  require(points!=0,Zeropointsinvalid);  require(msg.sender!=to,Selftransferinvalid);  //...}

修复后再执行一次测试即可通过了

FuzzTestingforZKInfrastructure

零知识基础设施（Zero-KnowledgeInfrastructure,ZKInfra）涉及编译、执行、生成证明与验证ZK电路的多个核心软体元件，对其进行漏洞检测至关重要。FuzzTesting是检测这些基础设施漏洞的一项强大工具，尤其适合处理其高复杂性与高安全需求的特性。

基于黑箱测试的随机变换与不变性检测

零知识基础设施的测试需要克服其内部实现的高度复杂性，黑箱测试因此成为检测漏洞的有效方法。在这种测试中，开发者将处理流程视作不可见的黑箱，仅根据输入和输出进行分析。

首先，测试工具会随机生成一个原始电路（C1），这些电路通常以小型DSL（特定领域语言）描述，用于模拟用户操作。接着，应用一系列随机变换来生成新电路（C2）。这些变换包括乘以1、加减随机表达式或其他等价操作，保证电路语义不变。随后将两个电路各自进行ZK工具的编译处理，若在任何阶段输出或行为不一致，即可定位到处理流程的漏洞。

例如，一个表达式P转换为P×1−0时，应保持输出一致，否则可能指向WitnessGenerator或编译器中的潜在问题。

持续且多元测试

由于零知识基础设施经常被用于Layer2协议，将乘载数亿美金以上的价值，其安全性至关重要，因此持续测试显得尤为必要。这可以通过自动化测试工具来实现，保证每次代码更新后都能迅速发现潜在漏洞。

测试还需要支持多种零知识DSL，如Circum、Gnark和Noir，确保适用于广泛场景。同时，FuzzTesting工具应具备自动化反馈功能，能够持续执行并根据发现的问题进行改进。此外，测试生成的输入应尽量简化，以便开发者快速理解并定位问题。

Part6:FormalVerification

FormalVerification（形式化验证）是一种透过数学方式验证软体是否符合特定FormalSpec（规格）的技术。对于智能合约而言，这种方法能有效检查合约在所有可能状态下的正确性。与FuzzTesting（模糊测试）相比，FormalVerification的验证过程更为系统化，能够覆盖所有可能的状态并「数学证明」合约逻辑的正确性。

然而，FormalVerification的实施通常需要严谨的规格定义，且计算成本较高。另一方面，FuzzTesting则透过随机输入测试合约，具有轻量且能快速发现边界问题的特性，但其测试范围有限，可能无法检测更深层的逻辑漏洞。

Certora

Certora提供了一套完整的工具来弥补这些不足，帮助开发者在现实环境中应用FormalVerification。其主要产品CertoraProver为智能合约提供了强大的验证框架，允许开发者定义规则并自动化验证合约的逻辑正确性。

Certora提供的工具旨在简化智能合约的形式化验证过程，核心功能包括：

• CertoraProver：一个验证平台，允许开发者使用CertoraVerificationLanguage(CVL)定义规格并测试合约逻辑。
• 整合式框架：透过设定档与脚本执行验证。
• 详细报告：自动生成验证结果，包含失败的详细原因与对应的测试输入，协助快速定位问题。

-->> 6/10 文章未完，请继续阅读

以上就是以太坊Devcon大会精选！十大关键技术全解析，将彻底改变Web3？的全部内容，望能这篇以太坊Devcon大会精选！十大关键技术全解析，将彻底改变Web3？可以帮助您解决问题，能够解决大家的实际问题是非常好学习网一直努力的方向和目标。