Fully Homomorphic Encryption — obliczenia na zaszyfrowanych danych bez ich odszyfrowywania. Wybierz poziom który pasuje do Ciebie.
Pomyśl o tym tak: kiedy wysyłasz paczkę kurierem, listonosz musi otworzyć paczkę żeby wiedzieć gdzie ją zanieść. Tak działa dzisiaj internet.
Twój bank musi zobaczyć Twoje saldo żeby sprawdzić czy możesz zapłacić. Twój lekarz musi przeczytać Twoje wyniki żeby postawić diagnozę. Google musi przeczytać Twój email żeby go przetłumaczyć.
Każdy serwis, który coś z Twoimi danymi robi — najpierw je widzi. To nie jest błąd w systemie. To fundamentalne ograniczenie matematyczne. Do teraz.
FHE pozwala wykonać obliczenia na zaszyfrowanych danych i dostać zaszyfrowany wynik — bez zobaczenia co jest w środku. Jak otwieranie koperty w ciemności.
// Dzisiaj (bez FHE) dane = "moje_wyniki_badań" zaszyfruj(dane) → #### wyślij(####) do serwera serwer.odszyfruj(####) → widzi dane! serwer.przetworz(dane) zaszyfruj(wynik) → %%%% odeślij(%%%%) // Z FHE (Octra) dane = "moje_wyniki_badań" zaszyfruj(dane) → #### wyślij(####) do serwera serwer.przetworz(####) → serwer NIGDY nie widzi! wynik_zaszyfrowany = %%%% odeślij(%%%%) → tylko Ty odszyfrujesz
Nie musisz rozumieć matematyki. Wystarczy jedna z tych analogii.
Cztery sytuacje z Twojego życia. Zobaczysz co jest możliwe gdy dane pozostają prywatne nawet podczas przetwarzania.
Chcesz zapytać AI o możliwą diagnozę. Dziś AI musi widzieć Twoje wyniki badań. Z FHE — analizuje zaszyfrowane dane i zwraca zaszyfrowaną odpowiedź. Tylko Ty ją odczytujesz.
Głosujesz online. Dziś ktoś musi zliczyć głosy — więc musi je zobaczyć. Z FHE zliczanie odbywa się na zaszyfrowanych kartach. Wynik jest poprawny matematycznie, nikt nie widział głosów.
Bank sprawdza czy zarabiasz wystarczająco na kredyt. Dziś musi zobaczyć Twoje przelewy. Z FHE dostaje tylko odpowiedź tak/nie — bez dostępu do kwot.
Dwie firmy chcą sprawdzić czy ich oferty cenowe się pokrywają, bez ujawniania cen. Z FHE: "masz nakładające się zakresy: TAK/NIE" — żadna strona nie widzi liczby drugiej.
Zanim FHE trafiło na blockchain — minęły dekady pracy kryptografów z całego świata.
>Kryptografowie zadali pytanie: czy można wykonywać obliczenia na zaszyfrowanych danych bez ich odszyfrowania? Nazwali to "privacy homomorphism". Nikt nie wiedział czy to w ogóle możliwe.
teoria — brak implementacji>Pierwsza w historii działająca implementacja FHE. Używała idealnych krat geometrycznych (ideal lattices). Była tysiące razy za wolna do użycia produkcyjnego — ale DZIAŁAŁA. Nagroda Turinga była tylko kwestią czasu.
→ praca Gentry 2009 (PDF)>Trzy nowe schematy, każdy 100× szybszy od poprzedniego. BGV — dla liczb całkowitych. CKKS — dla ML i genomiki (Google, IBM). TFHE — dla bramek logicznych (zama.ai, Concrete). FHE zaczyna być praktyczne.
impl: Microsoft SEAL · OpenFHE · Concrete>Octra zastępuje sekwencyjne kraty strukturą hipergrafu — co umożliwia masową równoległość operacji szyfrowanych. Wynik: 17 000 TPS na testnecie. Pierwszy blockchain gdzie każda transakcja może być zaszyfrowana end-to-end, natywnie, bez warstwy.
Czemu to zajęło 46 lat?
FHE jest matematycznie poprawne od 1978. Problem była wydajność — każda operacja na zaszyfrowanych danych wymaga złożonych obliczeń kryptograficznych. Postęp w algorytmice (BGV, CKKS, TFHE) i sprzęcie (GPU, ASIC) powoli zbliżał nas do punktu użyteczności.
Większość blockchainów jest przezroczystych. Każdy może zobaczyć ile masz tokenów, z kim handlujesz i co robisz. Octra zmienia to na poziomie fundamentalnym.
Token OCT to jak karta SIM — potrzebujesz jej żeby korzystać z sieci. Możesz kupić wOCT (wrapped OCT) na Uniswap — to ta sama wartość, tylko na sieci Ethereum.
Nie musisz niczego instalować żeby zrozumieć Octra. Zacznij od strony o sieci → lub sprawdź octrascan.io żeby zobaczyć transakcje w czasie rzeczywistym.
// Normalny blockchain (widoczny) od: 0xAlice do: 0xBob ile: 150 ETH ↑ KAŻDY to widzi na Etherscan // Octra (prywatny) od: [zaszyfrowane] do: [zaszyfrowane] ile: [zaszyfrowane] ↑ sieć wykonuje transakcję nie widząc żadnej wartości
Trzy najpopularniejsze podejścia do prywatności w krypto. Każde rozwiązuje inny problem. Zrozumienie różnicy to podstawa — bez tego marketing FHE, ZKP i MPC zlewa się w jedno.
ZKP (Zero-Knowledge Proof) — udowadnia że coś jest prawdą bez ujawniania dlaczego.
MPC (Multi-Party Computation) — oblicza wynik wspólnie między N stronami bez centralnego serwera.
FHE — oblicza na zaszyfrowanych danych na pojedynczym serwerze — bez zaufanej strony trzeciej.
| technologia | co robi | gdzie dane odszyfrowywane? | zaufana strona? | koszt | przykłady |
|---|---|---|---|---|---|
| ZKP | Dowodzi prawdziwości bez ujawniania danych | nigdy — tylko dowód | ✗ nie | niski–średni | zkSync, StarkNet, Zcash |
| MPC | Oblicza wynik między N stronami | u każdej strony (fragmenty) | zależy | wysoki (sieć) | Fireblocks, Shamir Secret |
| TE / SGX | Oblicza w izolowanym enklawie sprzętowym | wewnątrz enklawu (sprzęt) | ✓ Intel SGX | niski | Nym, Secret Network |
| FHE / HFHE | Oblicza bezpośrednio na szyfrze | nigdy | ✗ nie | wysoki* | Octra, fhEVM (zama) |
* HFHE na Octra osiąga 17k TPS dzięki masowej równoległości na hipergrafie. Szczegóły → sekcja 04.
Kiedy FHE, a kiedy ZKP?
ZKP jest tańsze i dojrzalsze — użyj do dowodzenia uprawnień (mam >18 lat, mam wystarczające saldo). FHE jest droższe, ale pozwala na pełne obliczenia — użyj do analizy zaszyfrowanych danych (model ML na zaszyfrowanych wynikach badań). W praktyce często uzupełniają się nawzajem.
Nie ma jednego "FHE" — to rodzina schematów. Każdy optymalizuje inny typ danych i zastosowanie. Wybór schematu ma fundamentalne znaczenie dla wydajności.
Dlaczego TFHE vs HFHE ma znaczenie?
TFHE wykonuje każdą bramkę logiczną sekwencyjnie — jak kalkulator z jednym przyciskiem na raz. HFHE przetwarza całe zestawy bramek równolegle przez hipergraf — jak wielordzeniowy procesor. Na praktycznym przykładzie: porównanie 1000 zaszyfrowanych ofert aukcji zajmuje w TFHE minuty. W HFHE — sekundy.
Nie każde FHE nadaje się do blockchaina. Poniżej dlaczego Octra wybrała własny schemat zamiast adaptować istniejące.
| właściwość | CKKS | TFHE | HFHE (Octra) |
|---|---|---|---|
| typ danych | liczby zmiennoprzecinkowe (przybliżone) | bity / bramki logiczne | liczby całkowite + bity (ct_int, ct_bool) |
| błąd obliczeń | akceptowalny (jak float64) | brak (dokładne) | brak (dokładne — int) |
| paralelizm | SIMD batching | sekwencyjne bramki (bottleneck) | masowa równoległość (hipergraf) |
| latencja bootstrapping | ~1–10s | ~0.1s / bit | n/a (17k TPS testnet) |
| ct_mul (cipher × cipher) | tak (noise grow) | tak (NAND) | brak — tylko plaintext×cipher |
| blockchain | słabe (błąd przybliżenia) | wolne (per-gate) | zaprojektowane natywnie |
| peer review | tak (IACR, IBM, Google) | tak (IACR, zama.ai) | w toku — closed-source |
| kiedy wybrać | ML inference, genomika, statystyki | EVM / fhEVM, logika boolean | native Octra — aukcje, saldo zaszyfrowane, circles |
* dane HFHE nieweryfikowalne zewnętrznie · TPS testnet · CKKS/TFHE: literatura IACR
Trzy tokeny / jednostki które musisz rozumieć żeby korzystać z sieci.
Inne projekty nakładają FHE na gotowy blockchain jak plaster. Octra zaprojektowała każdą warstwę stosu pod zaszyfrowane obliczenia.
oct://circle_id/path. Zaszyfrowane zasoby (sealed) — serwer nigdy nie widzi zawartości. Jak kontenery Docker, ale na blockchain i zaszyfrowane.ct_int, ct_bool. Kontrakty operują na szyfrach bez dostępu do plaintext.Octra vs fhEVM (zama.ai) — najczęściej zadawane pytanie.
fhEVM to pionierski projekt — ale FHE nakładane na EVM jako precompile. Każda operacja FHE to osobna transakcja Ethereum: ~10–50 TPS. Octra buduje L1 od zera gdzie FHE jest natywne: 17k TPS. Różne podejścia, różne kompromisy — fhEVM ma ekosystem Ethereum, Octra ma szybkość.
Nie jesteśmy stroną marketingową. Oto co jest niepewne i wymaga weryfikacji przed podjęciem decyzji o integracji lub inwestycji.
Każda warstwa stosu jest zaprojektowana pod FHE — nie doklejona na gotowy blockchain.
oct://circle_id/path. Zasoby mogą być sealed (zaszyfrowane) lub public. Klient rozszyfrowuje lokalnie — serwer nigdy nie widzi plaintext.
ct_int, ct_bool. Kontrakty operują na szyfrach bez dostępu do plaintext. Interfejs: JSON-RPC 2.0.
libpvac (zamknięty). Dostępne operacje: ct_add, ct_sub, ct_gte, ct_and, ct_or, ct_not. Brak ct_mul (ciphertext×ciphertext) — planowane.
Własny język kontraktów Octra kompilowany do WASM. Składnia inspirowana Rust/OCaml. Natywne typy zaszyfrowane.
contract.
| zasada | ✓ dobrze | ✗ źle |
|---|---|---|
| Słowo kluczowe | contract Foo { } | program Foo { } |
| Bool w state | is_open: int // 0 lub 1 | is_open: bool |
| Deploy fee | ou=200000 (0.2 OCT) | ou=1000 |
| Opłata tx | fee = recommendedFee × 1.5 | fee = recommendedFee |
| Mnożenie FHE | ct_add / ct_sub / ct_gte | ct_mul(a, b) // crash |
| Read-only fn | view fn get_count(): int | fn get_count(): int |
contract Vault { state { balance: ct_int owner: address locked: int // bool jako 0/1 ! } constructor() { self.owner = origin self.balance = encrypt(0) self.locked = 0 } fn deposit() { require(caller == self.owner) require(self.locked == 0) // value = natywny OCT przesłany z transakcją self.balance = ct_add(self.balance, encrypt(value)) } fn withdraw(amount: ct_int) { require(caller == self.owner) require(ct_gte(self.balance, amount)) self.balance = ct_sub(self.balance, amount) send(caller, decrypt(amount)) } fn lock() { require(caller == self.owner) self.locked = 1 } view fn is_locked(): int { return self.locked } }
HFHE udostępnia 6 operacji na ciphertext. Znajomość ich ograniczeń to fundament projektowania kontraktów.
ct_gte — odejmowanie poniżej zera nie powoduje revert, daje błędny wynik.ct_int pól.ct_gte przed ct_sub. Brak wbudowanego overflow protection w ciphertext arithmetic.
Wejdź na wallet.octra.org lub klient CLI. Format adresu: oct + base58(sha256(pubkey)). Zapisz seed phrase offline — brak odzyskiwania.
Discord → #faucet → wyślij adres. Potrzebujesz minimum 0.2 OCT (200 000 OU) na deploy + margines na opłatę (~1.5× recommendedFee).
W kliencie webowym: Dev Tools → compile contract. Wklej kod AML, kliknij compile → dostaniesz WASM bytecode. Pamiętaj: contract (nie program), bool jako int 0/1.
Zakładka deploy contract, ustaw ou=200000. Dostaniesz adres kontraktu oct.... Lub przez RPC: POST /rpc, metoda octra_deployContract.
Zakładka call contract: adres + nazwa funkcji. Metody view fn → tryb view (darmowe). Metody zmieniające stan → send call tx. Sprawdź na octrascan.io.
Jeden endpoint: POST /rpc. Parametry jako tablica pozycyjna — nie obiekt.
POST /rpc
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "METHOD_NAME",
"params": [] // tablica pozycyjna !
}
| metoda | params | opis |
|---|---|---|
| node_status | [] | Epoka, TPS, czas bloku |
| octra_balance | [address] | Saldo OCT + raw OU + nonce |
| octra_nonce | [address] | Potwierdzony nonce |
| octra_submit | [tx_json] | Wyślij podpisaną transakcję |
| octra_transaction | [hash] | Stan tx: pending/confirmed/rejected |
| octra_deployContract | [code, ou, from, fee, sig] | Deploy kontraktu AML |
| octra_callContract | [addr, fn, params, from, fee, sig] | Wywołanie funkcji (write) |
| octra_viewContract | [addr, fn, params] | Read-only — bez opłaty i podpisu |
view vs call: octra_viewContract to darmowe wywołanie read-only — nie wymaga podpisu ani opłaty. Używaj dla wszystkich view fn w kontraktach. octra_callContract zmienia stan — wymaga podpisanej transakcji i opłaty.