NEAR Protocole et Solana
Aujourd’hui, examinons deux des plates-formes de contrats intelligents les plus prometteuses au monde — Near Protocol et Solana. Bien qu’Ethereum domine toujours ce marché, le fait est que son manque d’évolutivité et ses frais élevés ont contraint la plupart des développeurs à rechercher des alternatives viables. Near et Solana sont devenus les deux premiers.
Qu’est-ce que Solana ?
Solana a été fondée en 2017 par Anatoly Yakovenko, qui avait auparavant travaillé chez DropBox. Yakovenko, avec Eric Williams et CTO Greg Fritzgerald, a créé Solana pour résoudre les problèmes existants dans Bitcoin et Ethereum. Le projet a attiré des investissements de Multicoin Capital, Foundation Capital, SLOW Capital, CMCC Global, Abstract Ventures, etc.
Caractéristiques de la blockchain Solana
● 50 000 transactions par seconde et 0,4 seconde de temps de bloc
● Le système peut fournir 28,4 millions de transactions par seconde sur un réseau de 40 gigabits.
● Solana utilise l’algorithme de consensus Proof-of-History.
Comment fonctionne la preuve d’histoire (PoH) ?
Dans un réseau décentralisé qui s’étend sur un vaste territoire, le consensus est essentiel. Bitcoin utilise le consensus de preuve de travail (PoW) pour prendre en charge le consensus. Bien que la méthode soit hautement sécurisée, il est difficile de ne pas ignorer son problème le plus important : le manque d’évolutivité. N’oubliez pas que Bitcoin ne peut effectuer que 7 transactions par seconde.
Solana utilise la preuve de l’histoire, dans laquelle il crée des enregistrements historiques pour prouver qu’un événement se produit à un moment précis. Voici quelques points que vous devez garder à l’esprit :
● L’algorithme utilise une fonction de délai vérifiable à haute fréquence qui nécessite un certain nombre d’étapes séquentielles pour terminer.
● Les transactions ou les événements cadencés au sein du réseau seront désignés par un compte de hachage unique, qui peut être vérifié publiquement.
● Le comptage permet au réseau de savoir exactement quand la transaction ou l’événement a eu lieu.
● Chaque nœud possède une horloge cryptographique qui permet de suivre l’heure du réseau et l’ordre des événements.
En raison de PoH, le réseau Solana prend en charge 50 000 transactions par seconde lors de l’exécution avec des GPU.
Qu’est-ce qu’un cluster Solana ?
Un cluster est un ensemble d’ordinateurs indépendants qui fonctionnent ensemble et peuvent être considérés comme un système singulier. Les principales caractéristiques du cluster sont les suivantes :
● Ils aident à vérifier la sortie de programmes non fiables soumis par les utilisateurs.
● Conserve un enregistrement de toute transaction ou événement effectué par un utilisateur.
● Il garde une trace des ordinateurs qui ont fait un travail significatif pour maintenir le réseau en marche.
● Il garde une trace de la possession d’actifs du monde réel.
Programmation en Solana
Les contrats intelligents dans Solana sont écrits en Rust ou C et compilés dans le bytecode Berkeley Packet Filter (BPF). Comme il y a plus d’outils disponibles, il est recommandé de coder en Rust. Les débutants doivent coder leurs programmes en utilisant le framework Anchor, ce qui simplifie l’exécution.
Solana a un modèle de compte unique qui est similaire aux fichiers du système d’exploitation Linux. Ils peuvent contenir des données arbitraires et contenir également des métadonnées sur la façon dont ils peuvent être consultés. Gardez cependant à l’esprit que les comptes ont une taille fixe et ne peuvent pas être redimensionnés.
Le modèle de programmation actuel de Solana peut vous obliger à déplacer la logique d’application hors chaîne ou à modifier la fonctionnalité pour qu’elle soit inefficace et limitée par la taille fixe du compte.
Exemple de contrat
#![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,Que se passe-t-il dans le contrat ?
● Tous les comptes auxquels accéder sont annotés dans la structure pour chaque appel avec #[derive(Accounts)].
● Les fonctions aident à initialiser les données de compte pour le propriétaire initial et l’achat. Cela permet à n’importe qui de l’acheter pour plus de jetons.
● Les données temporaires sont passées dans les paramètres de la fonction. Ces paramètres sont à l’intérieur des fonctions d’initialisation et d’achat. Cela inclut également le contexte de tenue des comptes requis pour la transaction.
● L’état du contrat est situé dans la structure ContentRecord. Ceci est en outre annoté avec #[compte] pour indiquer qu’il représente la présentation des données pour un compte.
Qu’est-ce que le protocole NEAR ?
Créé à l’été 2018, le protocole a été conçu pour créer l’environnement parfait pour les applications décentralisées en offrant des vitesses plus élevées, un débit plus élevé et une meilleure compatibilité avec d’autres chaînes. NEAR a une technique de partage unique et introduit un mécanisme de génération de blocs appelé « Doomslug » proposé en 2019. Doomslug permet une finalité pratique ou « Doomslug », garantissant que les blocs reçoivent la finalité en quelques secondes.
Le protocole NEAR est développé par le NEAR Collective, une communauté de développeurs et de chercheurs collaborant à la construction du projet. Certaines caractéristiques essentielles de NEAR sont :
● NEAR est un système partitionné qui permet une évolutivité infinie.
● Un protocole facile à utiliser, NEAR permet aux développeurs de créer des applications facilement et rapidement.
● NEAR n’est pas une chaîne latérale mais un protocole de couche 1.
● Les dApps créées à l’aide de NEAR s’exécutent au-dessus de la couche NEAR sous-jacente.
“ Lire l’article complet sur LearnNEAR.Club ”
Lien : https://learnnear.club/fr/near-protocole-et-solana/
Source :
le site web LearnNear.club
Médias :
Site internet | Twitter | Medium | Telegram|
