The Solcurity Standard – 安全标准区块链毕设代写

区块链毕设代写本文提供国外最新区块链项目源码下载,包括solidity,eth,fabric等blockchain区块链,The Solcurity Standard – 安全标准区块链毕设代写 是一篇很好的国外资料

The Solcurity Standard

Opinionated security and code quality standard for Solidity smart contracts. Based off work by BoringCrypto.

General Review Approach:

  • Read the project’s docs, specs, and whitepaper to understand what the smart contracts are meant to do.
  • Construct a mental model of what you expect the contracts to look like before checking out the code.
  • Glance over the contracts to get a sense of the project’s architecture. Tools like Surya can come in handy.
  • Compare the architecture to your mental model. Look into areas that are suprising.
  • Create a threat model and make a list of theoretical high level attack vectors.
  • Look at areas that can do value exchange. Especially functions like transfer, transferFrom, send, call, delegatecall, and selfdestruct. Walk backward from them to ensure they are secured properly.
  • Look at areas that interface with external contracts and ensure all assumptions about them are valid like share price only increases, etc.
  • Do a generic line-by-line review of the contracts.
  • Do another review from the perspective of every actor in the threat model.
  • Glance over the project’s tests + code coverage and look deeper at areas lacking coverage.
  • Run tools like Slither/Solhint and review their output.
  • Look at related projects and their audits to check for any similar issues or oversights.

Variables

  • V1 – Can it be internal?
  • V2 – Can it be constant?
  • V3 – Can it be immutable?
  • V4 – Is its visbility set? (SWC-108)
  • V5 – Is the purpose of the variable and other important information documented using natspec?
  • V6 – Can it be packed with an adjacent storage variable?
  • V7 – Can it be packed in a struct with more than 1 other variable?
  • V8 – Use full 256 bit types unless packing with other variables.
  • V9 – If it’s a public array, is a seperate function provided to return the full array?
  • V10 – Only use private to intentionally prevent child contracts from accessing the variable, prefer internal for flexibility.

Structs

  • S1 – Is a struct necessary? Can the variable be packed raw in storage?
  • S2 – Are its fields packed together (if possible)?
  • S3 – Is the purpose of the struct and all fields documented using natspec?

Functions

  • F1 – Can it be external?
  • F2 – Should it be internal?
  • F3 – Should it be payable?
  • F4 – Can it be combined with another similar function?
  • F5 – Validate all parameters are within safe bounds bounds, even if the function can only be called by a trusted user.
  • F6 – Is the checks before effects pattern followed? (SWC-107)
  • F7 – Check for front-running possibilities, such as the approve function. (SWC-114)
  • F8 – Is insufficient gas griefing possible? (SWC-126)
  • F9 – Are the correct modifiers applied, such as onlyOwner/requiresAuth?
  • F10 – Are return values are always assigned?
  • F11 – Write down and test invariants about state before a function can run correctly.
  • F12 – Write down and test invariants about the return or any changes to state after a function has run.
  • F13 – Take care when naming functions, because people will assume behavior based on the name.
  • F14 – If a function is intentionally unsafe (to save gas, etc), use an unwieldy name to draw attention to its risk.
  • F15 – Are all arguments, return values, side effects and other information documented using natspec?
  • F16 – If the function allows operating on another user in the system, do not assume msg.sender is the user being operated on.
  • F17 – If the function requires the contract is in an uninitialized state, do not use owner == address(0) to check.
  • F18 – Only use private to intentionally prevent child contracts from calling the function, prefer internal for flexibility.
  • F19 – Use virtual if there are legitimate (and safe) instances where a child contract may wish to override the function’s behavior.

Modifiers

  • M1 – Are no storage updates made (except in a reentrancy lock)?
  • M2 – Are external calls avoided?
  • M3 – Is the purpose of the modifier and other important information documented using natspec?

Code

  • C1 – Using SafeMath or 0.8 checked math? (SWC-101)
  • C2 – Are any storage slots read multiple times?
  • C3 – Are any unbounded loops/arrays used that can cause DoS? (SWC-128)
  • C4 – Use block.timestamp only for long intervals. (SWC-116)
  • C5 – Don’t use block.number for elapsed time. (SWC-116)
  • C7 – Avoid delegatecall wherever possible, especially to external (even if trusted) contracts. (SWC-112)
  • C8 – Do not update the length of an array while iterating over it.
  • C9 – Don’t use blockhash(), etc for randomness. (SWC-120)
  • C10 – Are signatures protected against replay with a nonce and block.chainid (SWC-121)
  • C11 – Ensure all signatures use EIP-712. (SWC-117 SWC-122)
  • C12 – Output of abi.encodePacked() shouldn’t be hashed if using >2 dynamic types. (SWC-133)
  • C13 – Careful with assembly, don’t use any arbitrary data. (SWC-127)
  • C14 – Don’t assume a specific ETH balance. (SWC-132)
  • C15 – Avoid insufficient gas griefing. (SWC-126)
  • C16 – Private data isn’t private. (SWC-136)
  • C17 – Updating a struct/array in memory won’t modify it in storage.
  • C18 – Never shadow state variables. (SWC-119)
  • C19 – Do not mutate function parameters.
  • C20 – Is calculating a value on the fly cheaper than storing it?
  • C21 – Are all state variables read from the correct contract (master vs. clone)?
  • C22 – Are comparison operators used correctly (>, <, >=, <=), especially to prevent off-by-one errors?
  • C23 – Are logical operators used correctly (==, !=, &&, ||, !), especially to prevent off-by-one errors?
  • C24 – Always multiply before dividing, unless the multiplication could overflow.
  • C25 – Are magic numbers replaced by a constant with an intuitive name?
  • C26 – If the recipient of ETH had a fallback function that reverted, could it cause DoS? (SWC-113)
  • C27 – Use SafeERC20 or check return values safely.
  • C28 – Don’t use msg.value in a loop.
  • C29 – Don’t use msg.value if recursive delegatecalls are possible (like if the contract inherits Multicall/Batchable).
  • C30 – Don’t assume msg.sender is always a relevant user.
  • C31 – Don’t use assert() unless for fuzzing or formal verification. (SWC-110)
  • C32 – Don’t use tx.origin for authorization, (SWC-115)
  • C33 – Don’t use address.transfer() or address.send(). Use .call.value(...)("") instead. (SWC-134)
  • C34 – When using low-level calls, ensure the contract exists before calling.
  • C35 – When calling a function with many parameters, use the named argument syntax.
  • C36 – Do not use assembly for create2. Prefer the modern salted contract creation syntax.
  • C37 – Do not use assembly to access chainif or contract code/size/hash. Prefer the modern Solidity syntax.
  • C38 – Use the delete keyword when setting a variable to a zero value (0, false, "", etc).
  • C39 – Comment the “why” as much as possible.
  • C40 – Comment the “what” if using obscure syntax or writing unconventional code.
  • C41 – Comment explanations + example inputs/outputs next to complex and fixed point math.
  • C42 – Comment explanations wherever optimizations are done, along with an estimate of much gas they save.
  • C43 – Comment explanations wherever certian optimizations are purposely avoided, along with an estimate of much gas they would/wouldn’t save if implemented.
  • C44 – Use unchecked blocks where overflow/underflow is impossible, or where if an underflow/overflow was to occur, reverting would be unhelpful (counters, etc). Comment explanations wherever unchecked is used, along with an estimate of how much gas it saves (if relevant).
  • C45 – Do not depend on Solidity’s arithmetic operator precedence rules. In addition to the use of parentheses to override default operator precedence, parentheses should also be used to emphasise it.
  • C46 – Expressions passed to logical/comparsion operators (&&/||/>=/==/etc) should not have side-effects.
  • C47 – When incrementing/decrementing a value, use ++/-- respectively to be explicit.

External Calls

  • X1 – Is an external contract call actually needed?
  • X2 – If there is an error, could it cause DoS? Like balanceOf() reverting. (SWC-113)
  • X3 – Would it be harmful if the call reentered into the current function?
  • X4 – Would it be harmful if the call reentered into the another function?
  • X5 – Is the result checked and errors dealt with? (SWC-104)
  • X6 – What if it uses all the gas provided?

Static Calls

  • S1 – Is an external contract call actually needed?
  • S2 – Is it actually marked as view in the interface?
  • S3 – If there is an error, could it cause DoS? Like balanceOf() reverting. (SWC-113)
  • S4 – If the call entered an infinite loop, could it cause DoS?

Events

  • E1 – Should any fields be indexed?
  • E2 – Is the creator of the relevant action included as an indexed field?
  • E3 – Do not index dynamic types like strings or bytes.
  • E4 – Is the when the event emitted and all fields documented using natspec?
  • E5 – Are all users/ids that are opreated on in functions that emit the event stored as indexed fields?

Contract

  • T1 – Use an SPDX license identifier.
  • T2 – Are events emitted for every storage mutating function?
  • T3 – Check for correct inheritance, keep it simple and linear. (SWC-125)
  • T4 – Use a receive() external payable function if the contract should accept transferred ETH.
  • T5 – Write down and test invariants about relationships between stored state.
  • T6 – Is the purpose of the contract and how it interacts with others documented using natspec?
  • T7 – The contract should be marked abstract if another contract must inherit it to unlock its full functionality.
  • T8 – Emit an appropriate event for any non-immutable variable set in the constructor that emits an event when mutated elsewhere.

Project

  • P1 – Use the right license (you must use GPL if you depend on GPL code, etc).
  • P2 – Unit test everything.
  • P3 – Fuzz test as much as possible.
  • P4 – Use the SMTChecker to prove invariants.
  • P5 – Run Slither/Solhint and review all findings.

DeFi

  • D1 – Check your assumptions about what other contracts do and return.
  • D2 – Don’t mix internal accounting with actual balances.
  • D3 – Be careful of relying on the raw token balance of a contract to determine earnings.
  • D4 – Don’t use spot price from an AMM as an oracle.
  • D5 – Use sanity checks to prevent oracle/price manipulation.
  • D6 – Do not trade on AMMs without receiving a price target off-chain or via an oracle.
  • D7 – Watch out for ERC-777 tokens. Even a token you trust could preform reentrancy if it’s an ERC-777.
  • D8 – Watch out for fee-on-transfer tokens. If they are unsupported, ensure that property is documented.
  • D9 – Watch out for rebasing tokens. If they are unsupported, ensure that property is documented.
  • D10 – Watch out for tokens that use too many or too few decimals. Ensure the max and min supported values are documented.

安全标准

固执己见的Solidity智能合约安全和代码质量标准。基于BoringCrypto的工作

一般审查方法:

  • 在签出代码之前,构建一个心理模型,描述您期望合同的样子
  • 将架构与您的心智模型进行比较。看看令人惊讶的地方
  • 创建威胁模型并列出理论上的高级攻击向量
  • 对合同进行逐行审查
  • 从威胁模型中每个参与者的角度再做一次回顾
  • 浏览项目的测试+代码覆盖率,并深入查看缺乏覆盖率的区域
  • 运行Slither/Solhint等工具并查看其输出
  • V1-它可以是内部的吗
  • V2-它可以是常数吗
  • V3-它是不可变的吗
  • V4-其可视性是否已设置?(SWC-108)
  • V5-变量的用途和其他重要信息是否使用natspec记录

变量

  • V6-它可以与相邻的存储变量打包吗
  • V7-是否可以将其打包到包含多个其他变量的结构中
  • V8-除非与其他变量打包,否则使用完整的256位类型
  • V9-如果它是一个公共数组,是否提供了一个单独的函数来返回完整数组
  • V10-仅使用private故意阻止子合约访问变量,为了灵活性,首选内部合约
  • S1-是否需要结构?变量是否可以在存储中原始包装
  • S2-其字段是否打包在一起(如果可能)
  • S3-是否使用natspec记录结构和所有字段的用途
  • F1-它可以是外部的吗
  • F2-它应该是内部的吗

结构

  • F3-是否应支付
  • F4-它可以与其他类似功能结合使用吗
  • F5-验证所有参数都在安全范围内,即使该函数只能由受信任的用户调用

函数

  • F6-是否遵循效果前检查模式?(SWC-107)
  • F7-检查是否存在前置运行的可能性,如批准功能。(SWC-114)
  • F8-是否可能存在气体过滤不足的情况?(SWC-126)
  • F9-是否应用了正确的修改器,如onlyOwner/RequiredAuth
  • F10-是否始终指定返回值
  • F12-写下并测试函数运行后返回或状态更改的不变量
  • F13-命名函数时要小心,因为人们会根据名称来假设行为
  • F14-如果某个功能是故意不安全的(为了节省气体等),请使用一个笨拙的名称来提醒注意其风险
  • F15-是否所有参数、返回值、副作用和其他信息都使用natspec记录
  • F16-如果该功能允许对系统中的另一个用户进行操作,请不要假定msg.sender是正在操作的用户
  • F17-如果函数要求协定处于未初始化状态,请不要使用owner==address(0)进行检查
  • F18-仅使用private故意阻止子合约调用函数,更喜欢使用internal以获得灵活性
  • F19-如果存在合法(且安全)的实例,其中子契约可能希望覆盖函数的行为,则使用虚拟
  • M1-是否未进行存储更新(重入锁中除外)
  • M2-是否避免外部呼叫
  • M3-是否使用natspec记录了修改器的用途和其他重要信息
  • C1-使用安全数学还是0.8检查数学?(SWC-101)
  • C2-是否有任何存储插槽被多次读取
  • C3-是否使用了任何可能导致拒绝服务的无界循环/数组?(SWC-128)

修饰符

  • C4-仅在长时间间隔内使用block.timestamp。(SWC-116)
  • C5-不要使用block.number表示经过的时间。(SWC-116)
  • C7-尽可能避免委派呼叫,尤其是对外部(即使受信任)合同。(SWC-112)

外部调用

  • C8-在对数组进行迭代时,不要更新数组的长度
  • C9-不要使用blockhash()等随机性。(SWC-120)
  • C10-是否使用nonce和block.chainid(SWC-121)保护签名不被重放?确保所有签名使用EIP-712。(SWC-117 SWC-122)
  • C12-如果使用&gt;2动态类型。(SWC-133)
  • C13-小心组装,不要使用任何任意数据。(SWC-127)
  • C14-不要假设特定的ETH余额。(SWC-132)
  • C15-避免气体过滤不足。(SWC-126)
  • C16-私有数据不是私有的。(SWC-136)
  • C17-更新内存中的结构/数组不会修改存储中的结构/数组
  • C18-永远不要对状态变量进行阴影处理。(SWC-119)
  • C19-不要改变功能参数
  • C20-动态计算值比存储值便宜吗
  • C21-是否所有状态变量都从正确的合同中读取(主合同与克隆合同)
  • C22-比较运算符是否正确使用(&gt;、&lt;、&gt;=、&lt;=),尤其是为了防止“一对一”错误
  • C23-是否正确使用了逻辑运算符(=,!=,&amp;,| |,!),尤其是为了防止一次关闭错误
  • C24-除非乘法可能溢出,否则始终在除法之前进行乘法
  • C25-幻数是否被具有直观名称的常数所取代
  • C26-如果ETH的接收者具有恢复的回退功能,是否会导致拒绝服务?(SWC-113)
  • C27-使用保险柜R20或安全检查返回值
  • C28-不要在循环中使用msg.value
  • C29-如果可以进行递归的delegatecall(比如如果契约继承了Multicall/Batchable),则不要使用msg.value
  • C30-不要假设msg.sender始终是相关用户
  • C31-除非用于模糊化或形式验证,否则不要使用assert()。(SWC-110)
  • C32-不使用tx.origin进行授权,(SWC-115)
  • C33-不使用address.transfer()或address.send()。改为使用.call.value(…)(“”)。(SWC-134)
  • C34-当使用低级调用时,请确保在调用之前存在合同
  • C35-调用具有多个参数的函数时,请使用命名参数语法
  • C36-不要将程序集用于create2。更喜欢现代salted契约创建语法
  • C37-不要使用程序集访问chainif或合同代码/大小/哈希。喜欢现代的坚固语法
  • C38-将变量设置为零值(0、false、“”等)时使用delete关键字
  • C39-尽可能多地评论“为什么”
  • C40-如果使用晦涩的语法或编写非常规代码,请注释“what”
  • C41-注释解释+复杂和定点数学旁边的示例输入/输出
  • C42-无论在哪里进行优化,都要对解释进行评论,并对其节省的汽油量进行估计
  • C43-评论故意避免认证优化的解释,以及如果实施这些优化将/不会节省多少汽油
  • C44-在无法溢出/下溢的情况下,或者如果发生下溢/上溢,则恢复将无济于事(计数器等),使用未经检查的块。在未选中的地方进行注释解释,并对其节省的汽油量进行估计(如果相关)
  • C45-不依赖于Solidity的算术运算符优先级规则。除了使用括号覆盖默认运算符优先级外,还应使用括号强调它
  • C46-传递给逻辑/比较运算符(&amp;/|//&gt;=/=/etc)的表达式不应有副作用
  • C47-当递增/递减一个值时,分别使用++/–以明确表示
  • X1-实际需要外部合同调用吗
  • X2-如果出现错误,是否会导致拒绝服务?比如()的平衡恢复。(SWC-113)
  • X3-如果调用重新进入当前函数,是否有害
  • X4-如果调用重新进入另一个函数,是否有害
  • X5-是否检查结果并处理错误?(SWC-104)
  • X6-如果它使用所有提供的气体怎么办
  • S1-实际需要外部合同调用吗

静态调用

  • S2-它在界面中是否实际标记为视图
  • S3-如果出现错误,是否会导致拒绝服务?比如()的平衡恢复。(SWC-113)
  • S4-如果呼叫进入无限循环,是否会导致拒绝服务
  • E1-是否应为任何字段编制索引
  • E2-相关操作的创建者是否包含在索引字段中
  • E3-不要索引字符串或字节等动态类型

合同

  • E4-是事件发出的时间,并且所有字段都使用natspec记录的时间吗
  • E5-在发出事件的函数中操作的所有用户/ID是否存储为
  • S3 – If there is an error, could it cause DoS? Like balanceOf() reverting. (SWC-113)
  • S4 – If the call entered an infinite loop, could it cause DoS?

项目,以及白皮书,以了解智能合约的作用
  • 在签出代码之前,构建一个心理模型,描述您期望合同的样子
  • 将架构与您的心智模型进行比较。看看令人惊讶的地方
  • 创建威胁模型并列出理论上的高级攻击向量
  • 对合同进行逐行审查
  • 从威胁模型中每个参与者的角度再做一次回顾
  • 浏览项目的测试+代码覆盖率,并深入查看缺乏覆盖率的区域
  • 运行Slither/Solhint等工具并查看其输出
  • V1-它可以是内部的吗
  • V2-它可以是常数吗
  • V3-它是不可变的吗
  • V4-其可视性是否已设置?(SWC-108)
  • V5-变量的用途和其他重要信息是否使用natspec记录
  • V6-它可以与相邻的存储变量打包吗
  • V7-是否可以将其打包到包含多个其他变量的结构中
  • V8-除非与其他变量打包,否则使用完整的256位类型
  • V9-如果它是一个公共数组,是否提供了一个单独的函数来返回完整数组
  • V10-仅使用private故意阻止子合约访问变量,为了灵活性,首选内部合约
  • S1-是否需要结构?变量是否可以在存储中原始包装
  • S2-其字段是否打包在一起(如果可能)
  • S3-是否使用natspec记录结构和所有字段的用途
  • F1-它可以是外部的吗
  • F2-它应该是内部的吗
  • F3-是否应支付
  • F4-它可以与其他类似功能结合使用吗
  • F5-验证所有参数都在安全范围内,即使该函数只能由受信任的用户调用
  • F6-是否遵循效果前检查模式?(SWC-107)
  • F7-检查是否存在前置运行的可能性,如批准功能。(SWC-114)
  • F8-是否可能存在气体过滤不足的情况?(SWC-126)
  • F9-是否应用了正确的修改器,如onlyOwner/RequiredAuth
  • F10-是否始终指定返回值
  • F12-写下并测试函数运行后返回或状态更改的不变量
  • F13-命名函数时要小心,因为人们会根据名称来假设行为
  • F14-如果某个功能是故意不安全的(为了节省气体等),请使用一个笨拙的名称来提醒注意其风险
  • F15-是否所有参数、返回值、副作用和其他信息都使用natspec记录
  • F16-如果该功能允许对系统中的另一个用户进行操作,请不要假定msg.sender是正在操作的用户
  • F17-如果函数要求协定处于未初始化状态,请不要使用owner==address(0)进行检查
  • F18-仅使用private故意阻止子合约调用函数,更喜欢使用internal以获得灵活性
  • F19-如果存在合法(且安全)的实例,其中子契约可能希望覆盖函数的行为,则使用虚拟
  • M1-是否未进行存储更新(重入锁中除外)
  • M2-是否避免外部呼叫
  • M3-是否使用natspec记录了修改器的用途和其他重要信息
  • C1-使用安全数学还是0.8检查数学?(SWC-101)
  • C2-是否有任何存储插槽被多次读取
  • C3-是否使用了任何可能导致拒绝服务的无界循环/数组?(SWC-128)
  • C4-仅在长时间间隔内使用block.timestamp。(SWC-116)
  • C5-不要使用block.number表示经过的时间。(SWC-116)
  • C7-尽可能避免委派呼叫,尤其是对外部(即使受信任)合同。(SWC-112)
  • C8-在对数组进行迭代时,不要更新数组的长度
  • C9-不要使用blockhash()等随机性。(SWC-120)
  • C10-是否使用nonce和block.chainid(SWC-121)保护签名不被重放?确保所有签名使用EIP-712。(SWC-117 SWC-122)
  • C12-如果使用&gt;2动态类型。(SWC-133)
  • C13-小心组装,不要使用任何任意数据。(SWC-127)
  • C14-不要假设特定的ETH余额。(SWC-132)
  • C15-避免气体过滤不足。(SWC-126)
  • C16-私有数据不是私有的。(SWC-136)
  • C17-更新内存中的结构/数组不会修改存储中的结构/数组
  • C18-永远不要对状态变量进行阴影处理。(SWC-119)
  • C19-不要改变功能参数
  • C20-动态计算值比存储值便宜吗
  • C21-是否所有状态变量都从正确的合同中读取(主合同与克隆合同)
  • C22-比较运算符是否正确使用(&gt;、&lt;、&gt;=、&lt;=),尤其是为了防止“一对一”错误
  • C23-是否正确使用了逻辑运算符(=,!=,&amp;,| |,!),尤其是为了防止一次关闭错误
  • C24-除非乘法可能溢出,否则始终在除法之前进行乘法
  • C25-幻数是否被具有直观名称的常数所取代
  • C26-如果ETH的接收者具有恢复的回退功能,是否会导致拒绝服务?(SWC-113)
  • C27-使用保险柜R20或安全检查返回值
  • C28-不要在循环中使用msg.value
  • C29-如果可以进行递归的delegatecall(比如如果契约继承了Multicall/Batchable),则不要使用msg.value
  • C30-不要假设msg.sender始终是相关用户
  • C31-除非用于模糊化或形式验证,否则不要使用assert()。(SWC-110)
  • C32-不使用tx.origin进行授权,(SWC-115)
  • C33-不使用address.transfer()或address.send()。改为使用.call.value(…)(“”)。(SWC-134)
  • C34-当使用低级调用时,请确保在调用之前存在合同
  • C35-调用具有多个参数的函数时,请使用命名参数语法
  • C36-不要将程序集用于create2。更喜欢现代salted契约创建语法
  • C37-不要使用程序集访问chainif或合同代码/大小/哈希。喜欢现代的坚固语法
  • C38-将变量设置为零值(0、false、“”等)时使用delete关键字
  • C39-尽可能多地评论“为什么”
  • C40-如果使用晦涩的语法或编写非常规代码,请注释“what”
  • C41-注释解释+复杂和定点数学旁边的示例输入/输出
  • C42-无论在哪里进行优化,都要对解释进行评论,并对其节省的汽油量进行估计
  • C43-评论故意避免认证优化的解释,以及如果实施这些优化将/不会节省多少汽油
  • C44-在无法溢出/下溢的情况下,或者如果发生下溢/上溢,则恢复将无济于事(计数器等),使用未经检查的块。在未选中的地方进行注释解释,并对其节省的汽油量进行估计(如果相关)
  • C45-不依赖于Solidity的算术运算符优先级规则。除了使用括号覆盖默认运算符优先级外,还应使用括号强调它
  • C46-传递给逻辑/比较运算符(&amp;/|//&gt;=/=/etc)的表达式不应有副作用
  • C47-当递增/递减一个值时,分别使用++/–以明确表示
  • X1-实际需要外部合同调用吗
  • X2-如果出现错误,是否会导致拒绝服务?比如()的平衡恢复。(SWC-113)
  • X3-如果调用重新进入当前函数,是否有害
  • X4-如果调用重新进入另一个函数,是否有害
  • X5-是否检查结果并处理错误?(SWC-104)
  • X6-如果它使用所有提供的气体怎么办
  • S1-实际需要外部合同调用吗
  • S2-它在界面中是否实际标记为视图
  • S3-如果出现错误,是否会导致拒绝服务?比如()的平衡恢复。(SWC-113)
  • S4-如果呼叫进入无限循环,是否会导致拒绝服务
  • E1-是否应为任何字段编制索引
  • E2-相关操作的创建者是否包含在索引字段中
  • E3-不要索引字符串或字节等动态类型
  • E4-是事件发出的时间,并且所有字段都使用natspec记录的时间吗
  • E5-在发出事件的函数中操作的所有用户/ID是否存储为
    • E1 – Should any fields be indexed?
    • E2 – Is the creator of the relevant action included as an indexed field?
    • E3 – Do not index dynamic types like strings or bytes.
    • E4 – Is the when the event emitted and all fields documented using natspec?
    • E5 – Are all users/ids that are opreated on in functions that emit the event stored as indexed fields?

    Contract

    • T1 – Use an SPDX license identifier.
    • T2 – Are events emitted for every storage mutating function?
    • T3 – Check for correct inheritance, keep it simple and linear. (SWC-125)
    • T4 – Use a receive() external payable function if the contract should accept transferred ETH.
    • T5 – Write down and test invariants about relationships between stored state.
    • T6 – Is the purpose of the contract and how it interacts with others documented using natspec?
    • T7 – The contract should be marked abstract if another contract must inherit it to unlock its full functionality.
    • T8 – Emit an appropriate event for any non-immutable variable set in the constructor that emits an event when mutated elsewhere.

    Project

    • P1 – Use the right license (you must use GPL if you depend on GPL code, etc).
    • P2 – Unit test everything.
    • P3 – Fuzz test as much as possible.
    • P4 – Use the SMTChecker to prove invariants.
    • P5 – Run Slither/Solhint and review all findings.

    DeFi

    • D1 – Check your assumptions about what other contracts do and return.
    • D2 – Don’t mix internal accounting with actual balances.
    • D3 – Be careful of relying on the raw token balance of a contract to determine earnings.
    • D4 – Don’t use spot price from an AMM as an oracle.
    • D5 – Use sanity checks to prevent oracle/price manipulation.
    • D6 – Do not trade on AMMs without receiving a price target off-chain or via an oracle.
    • D7 – Watch out for ERC-777 tokens. Even a token you trust could preform reentrancy if it’s an ERC-777.
    • D8 – Watch out for fee-on-transfer tokens. If they are unsupported, ensure that property is documented.
    • D9 – Watch out for rebasing tokens. If they are unsupported, ensure that property is documented.
    • D10 – Watch out for tokens that use too many or too few decimals. Ensure the max and min supported values are documented.

    部分转自网络,侵权联系删除区块链源码网

    www.interchains.cc

    https://www.interchains.cc/24744.html

    区块链毕设网(www.interchains.cc)全网最靠谱的原创区块链毕设代做网站 部分资料来自网络,侵权联系删除! 最全最大的区块链源码站 ! QQ3039046426
    区块链知识分享网, 以太坊dapp资源网, 区块链教程, fabric教程下载, 区块链书籍下载, 区块链资料下载, 区块链视频教程下载, 区块链基础教程, 区块链入门教程, 区块链资源 » The Solcurity Standard – 安全标准区块链毕设代写

    提供最优质的资源集合

    立即查看 了解详情