blockchain-2023-2024-spring

Forced money, ABI, Blockchain governance & more

`selfdestruct()`

вкарване на крипто в smart contract, независимо че няма payable функции
В момента, в който деплойнем СК на мрежа, понеже всички записи са immutable, не можем да го манипулираме
Можем обаче да го блокираме със selfdestruct примитива
- За да не остане ресурсът блокиран, можем да посочим адрес, на който да се изпрати останалият ресурс, независимо дали има payable функции

Side note proxy smart contract;

дърпане на killswitch-a на СК,
- update-ваме СК, прокси, което сочи към правилния СК; set-ваме properties, които пазят адреса на релеватния СК

// SPDX-License-Identifier: GPL-3.0

pragma solidity >=0.5.0 <0.9.0;


contract A {
    uint256 number = 10;

    function getNum() public view returns(uint256) {
        return number;
    }

    function destroySC(address payable _addr) public {
        selfdestruct(_addr);
    }

    function getBalance() public view returns(uint256) {
        return address(this).balance;
    }

    function receive() external payable { }
    function fallback() external payable { }

}

contract B {

    function getBalance() public view returns(uint256) {
        return address(this).balance;
    }
}

Ако се опитаме да достъпим property на унищожен СК, би трябвало да получим грешка:

oracle е вид СК, който може да изпълни транзакция извън ledger-а
- Oracles are data feeds that make off-chain data sources available to the blockchain for smart contracts

ABI

използва се, за да си взаимодействаме със СК, предоставя интерфейс към функциите, които ни интересуват
указва как виртуалната машина да интерпретира резултатите от извикване на функция, те са bytecodе
compile time creation, важи и за байткода
има значение дали един смарт контракт се вика вътре в ledger-а или се вика отвън

ledger world
A -> B // само подписване, заявката не напуска ledger-а

отвън $\to$ ledger world - трябва ни ABI, за да укажем как да се осъществи комуникацията

Пример

[
	...
	{ // една функция
		"inputs": [],
		"name": "getBalance",
		"outputs": [
			{
				"internalType": "uint256",
				"name": "",
				"type": "uint256"
			}
		],
		"stateMutability": "view",
		"type": "function"
	},
    ...

]

Bytecode

байткодът от компилацията

60806040525f600155603260025f6101000a81548160ff0219
16908360ff160217905550600a600260016101000a81548160ff...

Blockchain governance

начини, за да се развива един blockchain протокол

ERC(Ethereum request for comment)

всеки ethereum member може да пусне request for comment
предложения как да бъде развит ethereum по някакъв начин
- ако бъдат приети, стават стандарти
  - must be followed by each Ethereum user
  - канонизиран начин на комуникация
  - ERC20 token standard - ако деплoйваш крипто, трябва да спазваш правила(трябва да имаш 6 функции…)
❗ виртуалната машина не се променя, но има нови изисквания към потребителите
ERC721 - NFT
can be elevated to an EIP(Ethereum improvement proposal), по аналогия от BIP(Bitcoin Improvement Prosopal)
- става въпрос за по-сериозни промени
  - засягат самия прoтокол, не просто употребата
- must be implemented by each ethereum client(всеки node, всеки валидатор)
- handled by core developers
  - не всеки може да предложи EIP директно, само developers
- например Proof Of Stake промяната, EIP-3675
- ако по-голяма част от node-овете не го приемат, не се приема
  - 50/50 съгласие - по същество fork
    - fork(напр. bitcoin и bitcoin cash)
      - 1ви начин: разногласие по протокола
      - 2ри начин: при mine-ване на валиден блок няколко пъти, разклонения
- процесът е по-бавен и мъчителен

Side note Ethereum Magicians
хора, които директно са въвлечени в разработката

Security & Privacy

51% attack

В публичните мрежи е много трудно да се стигне до този случай, много изчислителна мощ е необходима

Race attack

race attack поражда race condition
- пускаме транзакция(към този, на когото трябва да платим), която е възможно най-малко атрактивна за валидаторите(стои си в pool-а известно време)
- след това си пускаме същата транзакция към нашия портфейл, но я правим доста по-атрактивна за валидаторите(напр. пускаме повече газ)
  Получаваме и ресурса, за който плащаме, и реално не плащаме.

Finney attack

Hal Finney - един от хората, които тясно са работили със Satoshi, той е открил тази атака
Пак поражда race condition
същата ситуация, но сме miner-и, mine-ваме блок, но не го обявяваме; в момента, в който вземем ресурса, го обявяваме

Miner генерира блок, където той включва транзакция от адрес A към адрес B, като и двата адреса принадлежат на него и засега не го обявява. Пуска същата транзакция от A към C(принадлежи на този, на когото miner-ът би трябвало да плати). Ако собственикът на C приеме транзакцията без тя да бъде потвърдена, miner-ът може да излъчи блока, в който е включена първата транзанкция, което прави втората невалидна.

Side note selfish mining

Re-entrancy attack

СК ни праща пари преди да е отбелязал, че ни ги е пратил
- циклично(рекурсивно) извикване след получаване и точене
DAO(Decentralized Autonomous Organization, фонд) hack

requires
transfer
subtract

и не са правили проверка за инициатора, а на tx.origin

Styling a smart contract

state fileds $\to$ events $\to$ modifiers $\to$ constructor $\to$ fallback function $\to$ receive functions $\to$ external functions $\to$ public functions $\to$ internal $\to$ private
transfer over send
require over assert and revert
- заради особености с газта, require връща остатъка налична газ, останалите – не
- assert използваме за ситуациите, до които никога не трябва да се стига
цикли ползваме колкото се може по-рядко
withdraw pattern over send/push pattern
- всеки сам да си взема това, което му се полага
calling internal or verified external SCs оver random SCs
- предпочитаме нашия си и верифициран код
Commitment schemes over revealing information directly
- начин, схема, която разкрива информацията постепенно и начасти
- самият СК не трябва да дава повече информация, отколкото е нужно
linear inheritane over multilpe inheritance
explicit code when developing - явно указваме големината на променливите
гледаме да пестим газ $\to$ гледаме да пестим памет

Security

check-effects-interaction pattern

В DAO hack случая е нарушен:

requires - check
transfer - interaction
subtract - effect

always check the balance of a contract
- forcing crypto in a SC
- Include automatic checks
sensitive information should be encrypted, публичен ledger, обикновено се ползват външни бази данни …
keep fallback as simple as possible
check for Tx payload length sent to fallbacks
implement speed bumps for withdrawing crypto(количеството изтеглени пари за единица време е ограничено)
limiting the rate of withdrawal amounts - ограничаване на количество на тeглене
restricting amount of crypto per user/contract in the early stage
- до следващите няколко блока, хората не могат да теглят…
implement automatic deprecation(optional) - напр. require, който зависи от номера на блока
never use tx.origin for authorization
use special libraries or oracles for randomness
use audited templates for specific smart contracts(openZeppelin, etc. )

General architecture guidelines

clearly define the purpose of the smart contract
have clear priorities(security, distribution, productivity, …)
clearly define what the SC is NOT expected to do
keeping the bulk of the bussiness logic in the middle layer
have an upgrade plan(proxy SC)
always deploy/test all the way
include bug-bounties in the development process
handle all expected(however unlikely) exceptions/scenarios
make the technological decisions last

Infura

❗ infura - услуга, един node за публична употреба, ако нямаме node няма как да се вържем с мрежата и да interact-ваме с протокола

node под наем
metamask ползва infura

Ethereum 2.0 - за събота

This site is open source. Improve this page.