Програмування Web3: як створюють децентралізовані програми?

Web3 — це не просто нові інструменти, а зміна підходу до створення застосунків. У децентралізованих застосунках (dApp) логіка та дані більше не належать одному серверу: ядро переноситься у смарт-контракти, а ідентичність користувача — у його гаманець. Такий зсув вимагає іншого мислення про архітектуру, безпеку, UX і DevOps.

Що таке Web3 і чим dApp відрізняється від звичайного застосунку?

У класичному вебі у нас є клієнт (браузер/мобільний застосунок) і сервер з БД. У Web3 серверна «правда» живе у блокчейні: код смарт-контрактів виконується валідаторами, дані транзакцій незмінні, а доступ до функцій визначається криптографічними ключами. dApp — це зв’язка смарт-контрактів, фронтенду, гаманця і, часто, децентралізованого сховища.

У результаті змінюються пріоритети: безпека контракту важливіша за швидкість релізу, незмінність важливіша за «гарячі фікси», а користувач сам володіє своїми активами — без «скидання пароля через e-mail».

Базові компоненти стека Web3

Блокчейн-рантайм

EVM-сумісні мережі (Ethereum, Polygon, BNB Smart Chain, Avalanche, Base та ін.) дозволяють писати контракти на Solidity/Vyper. Є й не-EVM платформи (Solana, Aptos, Sui), де контракти пишуть на Rust або Move.

Смарт-контракти

Це незмінні програми у блокчейні. Вони керують активами, визначають правила протоколу (DEX, лендинг, DAO) та виступають публічним API: будь-хто може викликати їх методи, сплативши газ.

Гаманці

Ключі користувача — це і його логін, і підпис запитів. Гаманці (MetaMask, Rabby, Phantom та ін.) виступають як провайдери: вони підключають фронтенд до мережі, показують користувачеві транзакції та підписують їх.

Децентралізоване сховище

Великі дані та статику часто зберігають у IPFS/Arweave/Filecoin. Хеш (CID) закріплюється в контракті, щоб будь-хто міг перевірити справжність вмісту.

Індексатори та субграфи

Для зручних запитів використовують The Graph або власні індексатори: вони «розпаковують» події блокчейну у зручні API, щоб фронтенд не робив сотні прямих викликів.

Життєвий цикл dApp: від ідеї до мейннету

Типовий шлях включає проєктування протоколу, написання та тестування контрактів, їх деплой у тестову мережу, розгортання фронтенду, аудит безпеки та випуск у мейннет. Важливо передбачити механізми апгрейду (через проксі), контроль доступу (рольова модель), аварійне відключення та плани міграцій.

Проєктування смарт-контрактів: інтерфейси, події, доступ

Інтерфейси

Дотримуйтесь стандартів (ERC-20/721/1155/4626/777/1271/4337 та ін.). Це забезпечує сумісність з гаманцями, біржами та аналітикою.

Події

Усе важливе логгуйте через події — їх легко індексувати та показувати на фронтенді. Події — це «канал зв’язку» вашого контракту з рештою світу.

Доступ і ролі

Мінімізуйте права. Використовуйте патерни Ownable/AccessControl, timelock-контракти для «прозорих» апгрейдів та екстрений паузер.

Мінімальний приклад ERC-20 на Solidity (демо)

pragma solidity ^0.8.20;

contract SimpleToken {
	string public name = "DemoToken";
	string public symbol = "DEMO";
	uint8 public decimals = 18;
	uint256 public totalSupply;

	mapping(address => uint256) public balanceOf;
	mapping(address => mapping(address => uint256)) public allowance;

	event Transfer(address indexed from, address indexed to, uint256 value);
	event Approval(address indexed owner, address indexed spender, uint256 value);

	constructor(uint256 initialSupply) {
		totalSupply = initialSupply * 10**decimals;
		balanceOf[msg.sender] = totalSupply;
		emit Transfer(address(0), msg.sender, totalSupply);
	}

	function transfer(address to, uint256 value) external returns (bool) {
		require(balanceOf[msg.sender] >= value, "INSUFFICIENT");
		unchecked { balanceOf[msg.sender] -= value; }
		balanceOf[to] += value;
		emit Transfer(msg.sender, to, value);
		return true;
	}

	function approve(address spender, uint256 value) external returns (bool) {
		allowance[msg.sender][spender] = value;
		emit Approval(msg.sender, spender, value);
		return true;
	}

	function transferFrom(address from, address to, uint256 value) external returns (bool) {
		uint256 allowed = allowance[from][msg.sender];
		require(balanceOf[from] >= value && allowed >= value, "INSUFFICIENT");
		unchecked {
			balanceOf[from] -= value;
			allowance[from][msg.sender] = allowed - value;
		}
		balanceOf[to] += value;
		emit Transfer(from, to, value);
		return true;
	}
}

На практиці краще використовувати перевірені реалізації (наприклад, OpenZeppelin), щоб знизити ризики та прискорити розробку.

Інструменти: Hardhat/Foundry, тестові мережі та деплой

Hardhat

Зручний для плагінів, JS/TS-скриптів і локальної мережі. Foundry — швидкий набір на Rust (forge/anvil/cast) з фокусом на тестах і fuzzing. Обидва інструменти добре доповнюють один одного.