13장. 디앱 운영 준비하기

아래 요약한 내용을 주의 깊게 다시 한 번 읽습니다.

이벤트 로깅

이더리움에서 이벤트는 블록체인에 영구적으로 기록되기 때문에 이벤트 정보를 얻을 수 있습니다.
이벤트 정보를 얻는 방법은 원하는 이벤트 발생을 watch하거나 이벤트를 검색해서 get하는 것입니다. 과거 이벤트 모두를 구할 수도 있습니다(allEvents).
이벤트 정보를 얻을 때는 이벤트의 인덱스 속성을 필터로 사용할 수 있습니다. 또한 get할 때는 fromBlock, toBlock과 같이 검색 조건도 작성할 수 있습니다. 필터와 검색 조건은 웹 클라이언트에서 이벤트 인스턴스를 생성할 때 인자로 작성됩니다.

업그레이드 가능한 라이브러리 디자인

프록시를 사용해 라이브러리를 업그레이드 할 수 있습니다.
라이브러리처럼 프록시 컨트랙트를 사용해서 컨트랙트를 업그레이드 할 수 있습니다. 또는 상태 변수와 로직을 두 개의 컨트랙트로 나누고 추상 Upgradeable 컨트랙트를 상속받도록 하는 방법도 있습니다.

14장. 보안 고려 사항

컨트랙트에서 보안은 매우 중요합니다. 본문 내용을 여러 번 읽어 봅니다.

아래 인용한 본문 내용과 요약 내용을 주의 깊게 다시 한 번 읽습니다.

일반적인 보안 취약점 이해

Data privacy
- If privacy is a requirement, you should store data in encrypted form rather than clear form.
  - 커밋-리빌 패턴 사용
    - 예) 경매에서 개찰 전까지 입찰 내용을 숨기도록 해야 함
Randomness
- Some Dapps, for example, betting games, occasionally need to randomize. You must ensure equal processing on all nodes without exposing the application to manipulation that takes advantage of the predictability of pseudo-random generators, and that can be tricky.
  - 커밋-리빌과 유사한 방법 사용
View functions
- You should be aware that functions defined as view might modify state variables
  - 솔리디티 0.5.0 이상에서는 컴파일러가 검사를 수행함
Gas limits
- You should be careful when setting the gas limits of your transactions, whether they’re low or high, because attackers might try to exploit them to their advantage.

난수 범위가 좁으면 반복적으로 숫자를 예측하고 해시 값을 생성하는 방법으로 알아낼 수 있습니다. 따라서 키와 같은 추가적인 값을 하나 더 생성하고 이것에 대한 해시 값도 같이 저장해 두어야 할 것 같습니다.

외부 컨트랙트 호출과 관련된 위험

대체할 방법이 없는 경우에만 외부 컨트랙트를 호출하도록 합니다.

다음은 외부 컨트랙트 호출과 관련해서 알아야 할 내용들입니다. 아래 각 항목에 대해 아는 것을 이야기 해 봅니다.

외부 호출로 실행하는 유형들과 개별 유형의 특징을 알아야 합니다.
외부 함수 호출할 때 할 수 있는 두 가지 일에 대해서 알아야 합니다.
외부 호출이 실패할 경우에 실패한 함수가 대응하는 두 가지 방법을 알고, 각각에 대한 대응 방법을 알아야 합니다.
외부 호출이 어떤 경우에 어떤 컨텍스트에서 실행되고 어떤 msg 객체가 사용되는지를 알아야 합니다.
외부 호출에 대한 가스 한도가 설정되는 방법을 알아야 합니다.

14.3 외부 호출을 더욱 안전하게 수행하는 방법이 확실하게 와 닿을 때 까지 반복해서 읽습니다.

알려진 보안 공격 회피하기

해당 내용을 스스로 설명할 수 있을 때 까지 여러번 반복해서 읽습니다.

아래 인용한 본문 내용과 요약 내용을 주의 깊게 다시 한 번 읽습니다.

Security attacks, strategies, and techniques

Attack objective	Attack strategy	Attack technique
Individual transaction manipulation	Race condition	Reentrancy, cross-function race condition
Favoring one transaction over others	Front-running	Front-running
Making contract unusable	Denial of service	Fallback calling revert(), exploiting gas limits

14.5 일반 보안 지침

ConsenSys Diligence 에서 관련된 내용을 찾아 학습합니다.

아래 인용한 본문 내용(일반 보안 지침)을 주의 깊게 다시 한 번 읽어 보고, 자주 볼 수 있도록 합니다.

Favor a simple contract design.
Amend code that raises compiler warnings.
Call external contracts as late as possible.
- The recommended pattern to adopt is called check–effects–interaction, according to which you structure a function on the following ordered steps.
  - Check
    - Validate that the message sender is authorized, function input parameters are valid, Ether being transferred is available, and so on. You generally do this directly through require statements or indirectly through function modifiers.
  - Effects
    - Change the state of your contract based on the validated function input.
  - Interaction
    - Call external contracts or libraries using the new contract state.
Plan for disaster
- Once a contract has been deployed, you can’t modify it. If you discover a bug or, even worse, a security flaw, and Ether is at risk, you can’t apply a hot-fix as you’d do on a conventional centralized application.
- You should plan for this eventuality beforehand and provide the contract owner with an emergency function, such as freeze() or selfDestruct().
- Such functions can disable the contract temporarily, until you understand the defect, or even permanently. Some developers have taken a more proactive approach and have implemented auto-freezing (or fail-safe) functionality based on contract state pre- or postcondition checks on each contract function. If the condition isn’t met, the contract moves into a fail-safe mode in which all or most of its functionality is disabled.
- Ideally you should also plan for an upgrade strategy.
Use linters
- The two most well-known Solidity linters are Solium (now Ethlint) (https://github.com/duaraghav8/Solium) and Solint (https://github.com/SilentCicero/solint).
Use security analysis frameworks
- If you want to go the extra mile, don’t stop at linters. Instead, aim at integrating security analysis into your development cycle with frameworks such as the Mythril Platform, which combines a variety of static and dynamic analyzers.
Follow the wisdom of the crowds
- If you’re not sure about the safety of smart contracts you’d like to connect to, you could look up their ratings in Panvala, a system that attempts to gather the level of security of smart contracts from their users.
Commission a formal security audit
- If your smart contract handles anything valuable, such as cryptocurrency or tokens, before going into production you should consider commissioning a formal security audit from one of the many consultancies that are starting to specialize in this area.