CELARДОКУМЕНТАЦИЯ CELAR.NETWORK →
Разработчикам · ДОКУМЕНТАЦИЯ CELAR

ConfidentialERC20: зашифрованные токены на стандартном Solidity

Celar полностью эквивалентен EVM — стандартный Solidity, кошельки, JSON-RPC и инструменты работают без изменений. Вычисления над шифротекстом приходят через прекомпилы, которые открывает стандартная библиотека: зашифрованные целые (euint8…euint64) и булевы значения (ebool), с которыми контракты работают как с 32-байтовыми хендлами, тогда как сам шифротекст находится в плоскости данных FHE.

Конфиденциальный перевод

import {TFHE, euint64, ebool} from "celar/TFHE.sol";

contract ConfidentialVault {
  mapping(address => euint64) private bal;

  function transfer(address to, euint64 amt) external {
    ebool ok = TFHE.and(
      TFHE.le(amt, bal[msg.sender]),      // funds check
      TFHE.le(amt, TFHE.sub(MAX, bal[to])) // overflow guard
    );
    euint64 m = TFHE.select(ok, amt, ZERO);
    bal[msg.sender] = TFHE.sub(bal[msg.sender], m);
    bal[to]         = TFHE.add(bal[to], m);
    // no revert, no branch, no leakage
  }
}

Без ветвлений по правилу, безопасно по построению

Обратите внимание: на зашифрованной проверке нет require ). Это и есть правило отсутствия ветвлений: ни один откат не может зависеть от зашифрованных данных, потому что откат, зависящий от данных, превратил бы конфиденциальное состояние в публичный оракул. Результаты сравнений попадают только в select — перевод переносит либо сумму, либо зашифрованный ноль, и транзакция корректна в обоих случаях. Правило проверяется при компиляции и повторно — анализом байт-кода при развёртывании: утечка приватности — это ошибка сборки, а не замечание аудита.

Что получает разработчик