NEAR PROTOCOL dan SOLANA

Pada artikel ini mari kita bahas dua platform smart contract yang paling menjanjikan saat ini – NEAR Protocol dan Solana. Walaupun Ethereum masih mendominasi pasar, namun fakta membuktikan bahwa Ethereum mengalami masalah skalabilitas dan gas fee yang besar dan memaksa para developer untuk mencari jalan alternatif. NEAR dan Solana sukses menjadi dua alternatif terdepan.

Apa Itu Solana?

Solana didirikan pada tahun 2017 oleh Anatoly Yakovenko, yang sebelumnya bekerja di DropBox. Yakovenko, bersama Eric Williams dan CTO Greg Fritzgerald, menciptakan Solana untuk memecahkan masalah-masalah yang terjadi pada jaringan Bitcoin dan Ethereum. Solana telah menarik minat para investor, antara lain Multicoin Capital, Foundation Capital, SLOW Capital, CMCC Global, Abstract Venture dan lainnya.

Fitur Menarik Pada Solana

• 50,000 transaksi per detik dan 0.4 detik finalisasi block
• Jaringan ini sanggup menangani 28,4 juta transaksi per detik pada saat dijalankan di atas 40 Gigabit Network.
• Solana menggunakan alghoritma konsensus PoH , atau Proof-of-History 

Bagaimana Proof-of-History Bekerja?

Dalam lingkup jaringan terdesentralisasi dengan cakupan besar, konsensus adalah elemen esensial. Bitcoin menggunakan konsensus Proof-of-Work. Meskipun metode ini dianggap memiliki keamanan tertinggi, namun tidak bisa disangkal ini juga menimbulkan masalah lainnya – yaitu masalah skalabilitas. Jangan lupa Bitcoin hanya sanggup menangani transaksi sebanyak 7 transaksi per detik.

Solana menggunakan Proof-of-History , menciptakan catatan (Historical Records) bahwa sebuah kejadian terjadi pada waktu yang spesifik. Berikut adalah point-point yang perlu kita ingat :

• Algoritmanya menggunakan Verifiable Delay Function dengan frekuensi tinggi, yang membutuhkan beberapa langkah berurutan untuk menyelesaikannya.
• Transaksi atau kejadian di dalam jaringan akan diajukan untuk mendapatkan sebuah hitungan hash yang unik, dan hash tersebut akan diverifikasi secara publik
• Hitungan tersebut memungkinkan seluruh jaringan mengetahui kapan transaksi atau kejadian itu terjadi.
• Setiap node dalam jaringan Solana, mempunyai semacam “cryptographic clock” yang membantu melacak waktu dalam jaringan dan kapan transaksi atau kejadian itu terjadi.

Dengan demikian, penggunaan Proof-of-History memungkinkan Solana mendukung 50,000 transaksi per detik dengan hardware yang menggunakan GPU.

Apa Itu Solana Cluster?

“Solana Cluster” adalah sebuah kelompok komputer yang masing-masing dimiliki secara independen namun dapat saling bekerjasama satu dengan lainnya dan dianggap sebagai satu kesatuan sistem. Fitur unggulan dari Solana Cluster adalah sebagai berikut :

• Mereka membantu memberikan verifikasi atas data yang dihasilkan oleh pengguna yang anonim
• Mencatat transaksi atau kejadian yang dilakukan pengguna.
• Membantu penelusuran dari set komputer manakah yang benar-benar bekerja untuk menjalankan sistem Solana secara keseluruhan.
• Membantu penelusuran dari kepemilikan atas aset dalam dunia nyata.

Pemrograman Di Dalam Solana

Smart Contract di Solana ditulis dengan bahasa pemrograman menggunakan Rust atau C dan dikompilasi menggunakan Berkeley Packet Filter ( BFP) bytecode. Dari beragam tools yang ada, direkomendasikan kepada para developer untuk menulis aplikasinya menggunakan Rust. Khusus pemula yang ingin menulis program mereka di Solana juga dapat menggunakan Anchor framework, ini memudahkan eksekusinya.

Solana mempunyai model account yang unik dan mirip dengan database file di dalam sistem operasi Linux. Mereka dapat menyimpan data arbitrase dan sanggup menyimpan metadata tentang bagaimana data tersebut diakses. Namun harap diingat, account tersebut mempunyai besaran file yang tetap dan tidak dapat dirubah.

Model pemrograman Solana saat ini memaksa para developer untuk memindahkan application logic menjadi off-chain (di luar blockchain) atau melakukan modifikasi namun menjadi tidak efisien karena terbatasnya alokasi besaran account tersebut.

Example Contract

#![feature(proc_macro_hygiene)]

use anchor_lang::prelude::*;
use anchor_spl::token::{self, TokenAccount, Transfer};

#[program]
pub mod plutocratic_hosting {
    use super::*;

    /// Initialize a new contract with initialized content.
    #[access_control(Initialize::validate(&ctx, nonce))]
    pub fn initialize(
        ctx: Context<Initialize>,
        price: u64,
        content: String,
        nonce: u8,
    ) -> ProgramResult {

        // Transfer funds to the contract vault.
        let cpi_accounts = Transfer {
            from: ctx.accounts.from.to_account_info().clone(),
            to: ctx.accounts.vault.to_account_info().clone(),
            authority: ctx.accounts.owner.clone(),
        };
        let cpi_program = ctx.accounts.token_program.clone();
        let cpi_ctx = CpiContext::new(cpi_program, cpi_accounts);
        token::transfer(cpi_ctx, price)?;

        // Initialize the content data.
        let content_record = &mut ctx.accounts.content;
        content_record.price = price;
        content_record.content = content;
        content_record.nonce = nonce;
        content_record.owner = *ctx.accounts.owner.to_account_info().key;
        content_record.vault = *ctx.accounts.vault.to_account_info().key;
        Ok(())

    }

    /// Purchase content address for new price, if transferring more tokens.
    #[access_control(check_funds(&ctx.accounts.content, price))]
    pub fn purchase(ctx: Context<Purchase>, price: u64, content: String) -> ProgramResult {
        // Transfer funds from contract back to owner.
        let seeds = &[
            ctx.accounts.content.to_account_info().key.as_ref(),
            &[ctx.accounts.content.nonce],
        ];
        let signer = &[&seeds[..]];
        let cpi_accounts = Transfer {
            from: ctx.accounts.vault.to_account_info().clone(),
            to: ctx.accounts.owner_token.to_account_info().clone(),
            authority: ctx.accounts.contract_signer.clone(),
        };
        let cpi_program = ctx.accounts.token_program.clone();
        let cpi_ctx = CpiContext::new_with_signer(cpi_program, cpi_accounts, signer);
        token::transfer(cpi_ctx, ctx.accounts.content.price)?;

        // Transfer funds from new owner to contract.
        let cpi_accounts = Transfer {
            from: ctx.accounts.new_owner_token.to_account_info().clone(),
            to: ctx.accounts.vault.to_account_info().clone(),
            authority: ctx.accounts.new_owner.clone(),
        };
        let cpi_program = ctx.accounts.token_program.clone();
        let cpi_ctx = CpiContext::new(cpi_program, cpi_accounts);
        token::transfer(cpi_ctx, price)?;

        // Overwrite content
        let content_record = &mut ctx.accounts.content;
        content_record.price = price;
        content_record.content = content;
        content_record.owner = *ctx.accounts.new_owner.to_account_info().key;

        Ok(())
    }
}

#[account]
pub struct ContentRecord {
    /// Price at which the current content is owned.
    pub price: u64,
    /// Content Data.
    pub content: String,
    /// Public key of current owner of the content.
    pub owner: Pubkey,
    /// Address for token program of funds locked in contract.
    pub vault: Pubkey,
    /// Nonce for the content, to create valid program derived addresses.
    pub nonce: u8,
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init)]
    content: ProgramAccount<'info, ContentRecord>,
    #[account(mut, "&vault.owner == contract_signer.key")]
    vault: CpiAccount<'info, TokenAccount>,
    /// Program derived address for the contract.
    contract_signer: AccountInfo<'info>,
    /// Token account the contract is made from.
    #[account(mut, has_one = owner)]
    from: CpiAccount<'info, TokenAccount>,
    /// Owner of the `from` token account.
    owner: AccountInfo<'info>,
    token_program: AccountInfo<'info>,
    rent: Sysvar<'info, Rent>,
}


impl<'info> Initialize<'info> {
    pub fn validate(ctx: &Context<Self>, nonce: u8) -> Result<()> {
        let signer = Pubkey::create_program_address(
            &[
                ctx.accounts.content.to_account_info().key.as_ref(),
                &[nonce],
            ],
            ctx.program_id,
        )
        .map_err(|_| ErrorCode::InvalidNonce)?;
        if &signer != ctx.accounts.contract_signer.to_account_info().key {
            return Err(ErrorCode::InvalidSigner.into());
        }
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Purchase<'info> {
    #[account(mut, has_one = vault)]
    content: ProgramAccount<'info, ContentRecord>,
    #[account(mut)]
    vault: CpiAccount<'info, TokenAccount>,
    #[account(seeds = [
        content.to_account_info().key.as_ref(),
        &[content.nonce],
    ])]
    contract_signer: AccountInfo<'info>,
    #[account(mut, has_one = owner)]
    owner_token: CpiAccount<'info, TokenAccount>,
    #[account(mut)]
    new_owner_token: CpiAccount<'info, TokenAccount>,
    #[account(signer)]
    new_owner: AccountInfo<'info>,
    owner: AccountInfo<'info>,
    token_program: AccountInfo<'info>,
}

fn check_funds(check: &ContentRecord, new_price: u64) -> Result<()> {
    if check.price >= new_price {
        return Err(ErrorCode::InsufficientFunds.into());
    }

    Ok(())
}

#[error]
pub enum ErrorCode {
    #[msg("The given nonce does not create a valid program derived address.")]
    InvalidNonce,
    #[msg("The derived signer does not match that which was given.")]
    InvalidSigner,
    #[msg("Insufficient funds provided to purchase route.")]
    InsufficientFunds,
}

Apa Yang Terjadi di Dalam Smart Contract Tersebut?

• Semua account yang akan diakses dijelaskan di dalam struktur untuk setiap call dengan tanda # [derive(Accounts)].
• Fungsi-fungsi tersebut untuk membantu melakukan inisialisasi (Initialize)  data account untuk pemilik awal dan melakukan transaksi (Purchase). Hal tersebut memungkinkan untuk pengguna lain melakukan transaksi kembali untuk mendapatkan token lebih banyak lagi.
• Data sementara kemudian diteruskan melalui parameter-parameter function. Parameter tersebut berada di dalam Initialize dan Purchase function. Termasuk juga Context yang menyimpan account yang terlibat dalam transaksi tersebut.

Apa Itu NEAR Protocol?

Dimulai saat musim panas di tahun 2018, protocol ini didesain untuk menciptakan environment sempurna untuk decentralized applications dengan menyediakan kecepatan dan throughput yang tinggi serta kompabilitas dengan jaringan blockchain lain. NEAR mempunyai teknik pemecahan (Sharding) yang unik dan pada 2019 memperkenalkan mekanisme penghasilan block (block producing) yang disebut “Doomslug”. Mekanisme ini memungkinkan jaringan NEAR menghasilkan finalisasi block dalam hitungan detik.

NEAR Protocol dikembangkan oleh NEAR Collective, sebuah komunitas developer dan ahli riset yang berkolaborasi membangun jaringan ini. Fitur utama NEAR adalah :

• NEAR menggunakan sistem pemecahan jaringan yang memungkinkan skalabilitas tak terhingga.
• Protokol yang mudah digunakan, memungkinkan Developer membangun aplikasi dalam waktu singkat dan mudah.
• NEAR bukanlah sidechain namun adalah Layer-1 Protocol.
• Dapp yang diciptakan menggunakan NEAR, berjalan di atas Layer NEAR

Apa itu NEAR Collective?

NEAR Collective berisikan didalamnya individu, organisasi dan kontributor yang secara terus menerus bekerja mengembangkan NEAR Protocol. NEAR Collective menulis code awal dan implementasinya di dalam NEAR Network. NEAR sepenuhnya desentralisasi, beroperasi secara independen dan tidak bisa dimatikan, dimanipulasi bahkan bagi mereka yang membangun dan mengembangkan.

NEAR Collective adalah sebuah organisasi nirlaba yang memfokuskan untuk menciptakan ekosistem di atas jaringan blockchain NEAR. Fungsinya membantu terbentuknya perkembangan dan aktifitas Governance. NEAR Collective mempunyai beberapa proyek, dimana blockchain NEAR adalah salah satunya di bawah naungan mereka.

Mekanisme Konsensus NEAR.

Mekanisme Konsensus yang diimplementasikan pada NEAR dinamakan Nightshade. Nightshade menganggap sistem jaringan adalah model dari single blockchain. Daftar dari semua transaksi dalam setiap block dibagi menjadi beberapa bagian besar (chunk), satu bagian untuk satu shard. Semua chunk diakumulasikan dalam satu block. Perhatikan bahwa setiap chunk hanya bisa divalidasi dari sekumpulan node yang memelihara shard tersebut.

Bicara mengenai validasi, komponen terpenting dari NEAR adalah validator. Validator-validator ini bertanggungjawab atas pemeliharan konsensus jaringan di dalam NEAR protocol. Validator adalah node yang diwajibkan menjaga server mereka nyala 100% untuk menjaga keberlangsungan sistem.

Beberapa point penting untuk diperhatikan :

• NEAR memilih validator network setiap epoch baru, berdasarkan berapa banyak NEAR yang mereka miliki dan pertaruhkan (stake) dalam network.
• Validator yang sudah terpilih didaftarkan ulang dengan secara otomatis mempertaruhkan ulang token mereka ditambah hadiah yang diperoleh.
• Validator potensial harus mempertaruhkan token NEAR mereka di atas ambang batas dinamis yang ditentukan oleh jaringan.
• Ada dua metode yang bisa dipilih oleh setiap validator untuk memperkuat stake mereka. Membeli NEAR dari kas mereka sendiri, atau meminjam via stake delegation.
• Imbalan yang diterima sesuai dengan proporsi stake, semakin banyak stake, maka reward akan semakin besar.

Konsensus berdasarkan dari konsensus chain terbesar, artinya ketika seorang block producer sukses menciptakan block baru, maka jaringan akan mengumpulkan signature dari setiap node validator. Berat dari sebuah block adalah akumulasi gabungan semua token yang dimiliki oleh para validator yang diikutsertakan dalam sebuah block. Sebagai tambahan, konsensus jaringan juga akan menggunakan tools tambahan untuk block finality dan mengenalkan tambahan kondisi pemotongan imbalan sebagai jaminan untuk keamanan jaringan.

Jaringan Aurora sudah diluncurkan di atas NEAR dan menyediakan pengalaman Layer 2 seperti dalam Ethereum. Beberapa keunggulan Aurora adalah :

• Membantu menghasilkan throughput menjadi ribuan transaksi per detik.
• Hanya 2 detik untuk block finality.
• Perkembangan ekosistem yang sangat baik untuk kedepannya.
• Kecilnya biaya transaksi, 1000x lebih rendah dibanding di jaringan utama Ethereum.
• Kompatibilitas dengan jaringan Ethereum. 

Example Contract

use near_sdk::borsh::{self, BorshDeserialize, BorshSerialize};
use near_sdk::collections::LookupMap;
use near_sdk::{env, near_bindgen, AccountId, Balance, Promise};

#[global_allocator]
static ALLOC: near_sdk::wee_alloc::WeeAlloc = near_sdk::wee_alloc::WeeAlloc::INIT;

#[derive(BorshDeserialize, BorshSerialize)]
pub struct ContentRecord {
    pub price: Balance,
    pub content: String,
    pub owner: AccountId,
}

#[near_bindgen]
#[derive(BorshDeserialize, BorshSerialize)]
pub struct ContentTracker {
    values: LookupMap<String, ContentRecord>,
    contract_owner: AccountId,
}

impl Default for ContentTracker {
    fn default() -> Self {
        let contract_owner = env::predecessor_account_id();
        Self {
            values: LookupMap::new(b"v".to_vec()),
            contract_owner,
        }
    }
}

#[near_bindgen]
impl ContentTracker {
    /// Gets content at a given route.
    pub fn get_route(&self, route: String) -> Option<String> {
        self.values.get(&route).map(|v| v.content)
    }

    /// Purchases a route based on funds sent to the contract.
    #[payable]
    pub fn purchase(&mut self, route: String, content: String) {
        let deposit = env::attached_deposit();
        assert!(deposit > 0);
        if let Some(entry) = self.values.get(&route) {
            assert!(
                deposit > entry.price,
                "Not enough deposit to purchase route, price: {} deposit: {}",
                entry.price,
                deposit
            );


            // Refund purchase to existing owner
            Promise::new(entry.owner).transfer(entry.price);
        }


        // Update record for the contract state.
        self.values.insert(
            &route,
            &ContentRecord {
                price: deposit,
                content,
                owner: env::predecessor_account_id(),
            },
        );
    }


    /// Allows owner of the contract withdraw funds.
    pub fn withdraw(&mut self) {
        assert_eq!(env::predecessor_account_id(), self.contract_owner);


        // Send the contract funds to the contract owner
        Promise::new(self.contract_owner.clone()).transfer(env::account_balance());
    }
}

What is going on in the contract?

Jadi apa yang terjadi pada Smart Contract di atas? Mari kita lihat :

• Contract dijelaskan oleh #[near_bridgen] di dalam ContentTracker dan ini mirip dengan sebuah constructor dalam Solidity, dan akan dipanggil  (call) saat contract diluncurkan.

• Purchase Function dijelaskan dengan #[payable]

• Contract mengikutsertakan asynchronous calls dalam bentuk Promise::new(..).transfer(…); lines.

• Struktur data pada LookupMap<String, ContentRecord> menangani “value lookup”, dan memungkinkan mengakses storage. Mempunyai kemiripan pada fitur “mapping” pada Solidity.

Kesimpulan

Baik Solana maupun NEAR Protocol adalah platform smart contract yang sedang menjadi sorotan para penggiat aktif dalam dunia blockchain dan cryptocurrency. Keduanya memiliki fitur unik yang sama-sama memberikan solusi kepada masalah utama dalam dunia desentralisasi, yaitu kecepatan. Kedua platform tersebut kedepannya akan terus tumbuh dan sangat menjanjikan.