Programy

Na Solanie "smart kontrakty" nazywane są programami. Programy są wdrażane w łańcuchu bloków do kont, które zawierają skompilowany plik wykonywalny programu. Użytkownicy wchodzą w interakcję z programami, wysyłając transakcje zawierające instrukcje, które określają, co program ma zrobić.

Kluczowe informacje

• Programy to konta zawierające kod wykonywalny, zorganizowany w funkcje zwane instrukcjami.
• Chociaż programy są bezstanowe, mogą zawierać instrukcje tworzące i aktualizujące inne konta do przechowywania danych.
• Autorytet aktualizacji może aktualizować programy. Po usunięciu tego autorytetu program staje się niezmienny.
• Użytkownicy mogą zweryfikować, czy dane konta programu w łańcuchu bloków odpowiadają jego publicznemu kodowi źródłowemu dzięki weryfikowalnym kompilacjom.

Pisanie programów na Solanie

Programy na Solanie są głównie pisane w języku programowania Rust, przy użyciu dwóch popularnych podejść do rozwoju:

• Anchor: Framework zaprojektowany do tworzenia programów na Solanie. Umożliwia szybsze i prostsze pisanie programów, wykorzystując makra Rust do redukcji kodu szablonowego. Dla początkujących zaleca się rozpoczęcie od frameworka Anchor.

• Natywny Rust: Podejście polegające na pisaniu programów na Solanie w języku Rust bez użycia frameworków. Oferuje większą elastyczność, ale wiąże się z większą złożonością.

Aktualizowanie programów na Solanie

Aby dowiedzieć się więcej o wdrażaniu i aktualizowaniu programów, zobacz stronę wdrażanie programów.

Programy mogą być bezpośrednio modyfikowane przez konto wyznaczone jako "autorytet aktualizacji", którym zazwyczaj jest konto, które pierwotnie wdrożyło program. Jeśli autorytet aktualizacji zostanie odwołany i ustawiony na None, program staje się niezmienny i nie może być już aktualizowany.

Programy weryfikowalne

Weryfikowalne kompilacje pozwalają każdemu sprawdzić, czy kod programu na łańcuchu bloków odpowiada jego publicznemu kodowi źródłowemu, co umożliwia wykrycie rozbieżności między kodem źródłowym a wdrożonymi wersjami.

Społeczność deweloperów Solana wprowadziła narzędzia wspierające weryfikowalne kompilacje, umożliwiając zarówno deweloperom, jak i użytkownikom weryfikację, czy programy na łańcuchu bloków dokładnie odzwierciedlają ich publicznie udostępniony kod źródłowy.

• Wyszukiwanie zweryfikowanych programów: Aby szybko sprawdzić zweryfikowane programy, użytkownicy mogą wyszukać adres programu w Solana Explorer. Przykład zweryfikowanego programu można zobaczyć tutaj.

• Narzędzia weryfikacyjne: Narzędzie Solana Verifiable Build CLI stworzone przez Ellipsis Labs umożliwia użytkownikom niezależną weryfikację programów na łańcuchu bloków względem opublikowanego kodu źródłowego.

• Wsparcie dla weryfikowalnych kompilacji w Anchor: Anchor oferuje wbudowane wsparcie dla weryfikowalnych kompilacji. Szczegóły można znaleźć w dokumentacji Anchor.

Berkeley Packet Filter (BPF)

Solana wykorzystuje LLVM (Low Level Virtual Machine) do kompilacji programów do plików w formacie ELF (Executable and Linkable Format). Pliki te zawierają niestandardową wersję bajtkodu eBPF Solany, zwaną "Solana Bytecode Format" (sBPF). Plik ELF zawiera binarny kod programu i jest przechowywany na łańcuchu bloków w koncie wykonawczym, gdy program jest wdrażany.

Wbudowane programy

Programy ładujące

Każdy program jest własnością innego programu, który jest jego loaderem. Obecnie istnieje pięć programów ładujących:

Te loadery są niezbędne do tworzenia i zarządzania programami niestandardowymi:

• Wdrożenie nowego programu lub bufora
• Zamknięcie programu lub bufora
• Ponowne wdrożenie / aktualizacja istniejącego programu
• Przekazanie uprawnień nad programem
• Finalizacja programu

Loader-v3 i loader-v4 obsługują modyfikacje programów po ich początkowym wdrożeniu. Uprawnienia do tego są regulowane przez autorytet programu, ponieważ własność konta każdego programu należy do loadera.

Programy wstępnie skompilowane

Program Ed25519

Program ed25519 przetwarza instrukcję. Pierwszy u8 to liczba podpisów do sprawdzenia, po której następuje jednobajtowe wypełnienie. Następnie serializowana jest następująca struktura, jedna dla każdego podpisu do sprawdzenia.

struct Ed25519SignatureOffsets {
    signature_offset: u16,             // offset to ed25519 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get message data
}

Pseudokod weryfikacji podpisu:

process_instruction() {
    for i in 0..count {
        // i'th index values referenced:
        instructions = &transaction.message().instructions
        instruction_index = ed25519_signature_instruction_index != u16::MAX ? ed25519_signature_instruction_index : current_instruction;
        signature = instructions[instruction_index].data[ed25519_signature_offset..ed25519_signature_offset + 64]
        instruction_index = ed25519_pubkey_instruction_index != u16::MAX ? ed25519_pubkey_instruction_index : current_instruction;
        pubkey = instructions[instruction_index].data[ed25519_pubkey_offset..ed25519_pubkey_offset + 32]
        instruction_index = ed25519_message_instruction_index != u16::MAX ? ed25519_message_instruction_index : current_instruction;
        message = instructions[instruction_index].data[ed25519_message_data_offset..ed25519_message_data_offset + ed25519_message_data_size]
        if pubkey.verify(signature, message) != Success {
            return Error
        }
    }
    return Success
}

Program Secp256k1

Program secp256k1 przetwarza instrukcję, która jako pierwszy bajt przyjmuje liczbę następujących struktur zserializowanych w instruction data:

struct Secp256k1SignatureOffsets {
    secp_signature_offset: u16,            // offset to [signature,recovery_id] of 64+1 bytes
    secp_signature_instruction_index: u8,  // instruction index to find signature
    secp_pubkey_offset: u16,               // offset to ethereum_address pubkey of 20 bytes
    secp_pubkey_instruction_index: u8,     // instruction index to find pubkey
    secp_message_data_offset: u16,         // offset to start of message data
    secp_message_data_size: u16,           // size of message data
    secp_message_instruction_index: u8,    // instruction index to find message data
}

Pseudokod weryfikacji odzyskiwania:

process_instruction() {
  for i in 0..count {
      // i'th index values referenced:
      instructions = &transaction.message().instructions
      signature = instructions[secp_signature_instruction_index].data[secp_signature_offset..secp_signature_offset + 64]
      recovery_id = instructions[secp_signature_instruction_index].data[secp_signature_offset + 64]
      ref_eth_pubkey = instructions[secp_pubkey_instruction_index].data[secp_pubkey_offset..secp_pubkey_offset + 20]
      message_hash = keccak256(instructions[secp_message_instruction_index].data[secp_message_data_offset..secp_message_data_offset + secp_message_data_size])
      pubkey = ecrecover(signature, recovery_id, message_hash)
      eth_pubkey = keccak256(pubkey[1..])[12..]
      if eth_pubkey != ref_eth_pubkey {
          return Error
      }
  }
  return Success
}

To pozwala użytkownikowi określić dowolne instruction data w transakcji dla danych podpisu i wiadomości. Określając specjalny sysvar instrukcji, można również otrzymać dane bezpośrednio z transakcji.

Koszt transakcji będzie liczony jako liczba podpisów do weryfikacji pomnożona przez mnożnik kosztu weryfikacji podpisu.

Program Secp256r1

Program secp256r1 przetwarza instrukcję. Pierwszy u8 to liczba podpisów do sprawdzenia, po której następuje pojedynczy bajt wypełnienia. Następnie serializowana jest poniższa struktura, jedna dla każdego podpisu do sprawdzenia:

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to compact secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to compressed public key of 33 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get message data
}

Pseudokod weryfikacji podpisu:

process_instruction() {
    if data.len() < SIGNATURE_OFFSETS_START {
        return Error
    }

    num_signatures = data[0] as usize
    if num_signatures == 0 || num_signatures > 8 {
        return Error
    }

    expected_data_size = num_signatures * SIGNATURE_OFFSETS_SERIALIZED_SIZE + SIGNATURE_OFFSETS_START
    if data.len() < expected_data_size {
        return Error
    }

    for i in 0..num_signatures {
        offsets = parse_signature_offsets(data, i)

        signature = get_data_slice(data, instruction_datas, offsets.signature_instruction_index, offsets.signature_offset, SIGNATURE_SERIALIZED_SIZE)

        if s > half_curve_order {
            return Error
        }

        pubkey = get_data_slice(data, instruction_datas, offsets.public_key_instruction_index, offsets.public_key_offset, COMPRESSED_PUBKEY_SERIALIZED_SIZE)

        message = get_data_slice(data, instruction_datas, offsets.message_instruction_index, offsets.message_data_offset, offsets.message_data_size)

        if !verify_signature(signature, pubkey, message) {
            return Error
        }
    }

    return Success
}

Uwaga: Niskie wartości S są wymuszane dla wszystkich podpisów, aby uniknąć przypadkowej modyfikowalności podpisu.

Programy podstawowe

Geneza klastra Solana zawiera listę specjalnych programów, które zapewniają podstawowe funkcjonalności dla sieci. Historycznie były one określane jako programy "natywne" i były dystrybuowane razem z kodem walidatora.