🥇Utreexo. սեղմում է բազմաթիվ UTXO Bitcoin

Հե՜յ Հաբր։

Bitcoin ցանցում բոլոր հանգույցները, կոնսենսուսի միջոցով, համաձայնում են UTXO-ների մի շարքի շուրջ՝ քանի մետաղադրամ է հասանելի ծախսելու համար, կոնկրետ ում և ինչ պայմաններում: UTXO հավաքածուն վավերացնող հանգույցի համար պահանջվող տվյալների նվազագույն հավաքածուն է, առանց որի հանգույցը չի կարողանա ստուգել մուտքային գործարքների և դրանք պարունակող բլոկների վավերականությունը:

Այս առումով ամեն կերպ փորձեր են արվում կրճատել այս հավաքածուի պահպանված ներկայացումը, սեղմել այն՝ չկորցնելով անվտանգության երաշխիքները։ Որքան փոքր է պահված տվյալների ծավալը, այնքան ցածր է վավերացնող հանգույցի սկավառակի տարածության պահանջները, ինչը վավերացնող հանգույցի գործարկումն էժան է դարձնում, թույլ է տալիս ընդլայնել ցանցը և դրանով իսկ բարձրացնել ցանցի կայունությունը:

Այս գրառման մեջ մենք կտեղադրենք Rust-ի վերջին առաջարկի նախատիպը համահեղինակից Lightning ցանցային թուղթ, Թադեուս Դրիյա - Utreexo՝ դինամիկ հեշի վրա հիմնված կուտակիչ, որը օպտիմիզացված է Bitcoin UTXO հավաքածուի համար, որը թույլ է տալիս նվազեցնել սկավառակի տարածության պահանջները վավերացնող հանգույցների համար:

Ինչումն է խնդիրը?

Բիթքոյնի բազմամյա խնդիրներից մեկը դրա մասշտաբայնությունն է: «Ձեր սեփական բանկի» գաղափարը ցանցի մասնակիցներից պահանջում է օգտագործելու համար հասանելի բոլոր միջոցների գրառումները: Bitcoin-ում հասանելի միջոցները արտահայտվում են որպես չծախսված արդյունքների մի շարք՝ UTXO-կոմպլեկտ: Թեև սա առանձնապես ինտուիտիվ ներկայացում չէ, այն ձեռնտու է իրագործման արդյունավետության տեսանկյունից այն ներկայացուցչության նկատմամբ, որտեղ յուրաքանչյուր «դրամապանակ» ունի «մնացորդ» որպես առանձին մուտք, ինչպես նաև ավելացնում է գաղտնիությունը (օրինակ. Մետաղադրամ).

Կարևոր է տարբերակել գործարքների պատմությունը (ինչը կոչվում է բլոկչեյն) և համակարգի ներկա վիճակը: Bitcoin գործարքների պատմությունը ներկայումս զբաղեցնում է մոտ 200 ԳԲ սկավառակի տարածություն և շարունակում է աճել: Այնուամենայնիվ, համակարգի վիճակը շատ ավելի փոքր է՝ 4 ԳԲ-ի սահմաններում, և հաշվի է առնում միայն այն փաստը, որ ինչ-որ մեկը ներկայումս ունի մետաղադրամներ: Այս տվյալների ծավալը նույնպես ավելանում է ժամանակի ընթացքում, բայց շատ ավելի դանդաղ տեմպերով և երբեմն նույնիսկ նվազման միտում ունի (տես CDPV):

Թեթև հաճախորդների (SPVs) առևտրային անվտանգության երաշխիքներ՝ մասնավոր բանալիներից բացի ոչ մի նվազագույն վիճակ (UTXO-set) պահելու հնարավորության համար:

UTXO և UTXO-set

UTXO-ն (Unspent Transaction Output) չծախսված գործարքի արդյունքն է, գործարքներում փոխանցված յուրաքանչյուր Satoshi-ի ճանապարհորդության վերջնակետը: Չծախսված ելքերը դառնում են նոր գործարքների մուտքեր և այդպիսով ծախսվում են (ծախսվում) և հեռացվում UTXO հավաքածուից:

Նոր UTXO-ները միշտ ստեղծվում են գործարքներով.

coinbase գործարքներ առանց մուտքերի. ստեղծել նոր UTXO-ներ, երբ հանքագործները թողարկում են մետաղադրամներ
կանոնավոր գործարքներ. ստեղծել նոր UTXO-ներ՝ միաժամանակ ծախսելով գոյություն ունեցող UTXO-ների որոշակի փաթեթ

UTXO-ի հետ աշխատելու գործընթացը.

Դրամապանակները հաշվում են ծախսելու համար հասանելի մետաղադրամների քանակը (մնացորդը)՝ հիմնվելով այս դրամապանակին ծախսելու համար հասանելի UTXO-ի քանակի վրա:

Յուրաքանչյուր վավերացնող հանգույց, կրկնակի ծախսերի փորձերը կանխելու համար, պետք է վերահսկի հավաքածուն Ամբողջ UTXO ստուգելիս յուրաքանչյուր գործարքներ յուրաքանչյուր արգելափակել.

Հանգույցը պետք է ունենա տրամաբանություն.

Հավելումներ UTXO-սեթում
Ջնջումներ UTXO-set-ից
Կոմպլեկտում մեկ UTXO-ի առկայությունը ստուգելը

Գոյություն ունեն բազմության մասին պահվող տեղեկատվության պահանջները նվազեցնելու եղանակներ՝ միաժամանակ պահպանելով տարրեր ավելացնելու և հեռացնելու, ստուգելու և ապացուցելու կարողությունը հավաքածուում տարրի առկայությունը՝ օգտագործելով ծածկագրային կուտակիչներ.

Մարտկոցներ UTXO-ի համար

Մի քանի UTXO-ներ պահելու համար մարտկոցներ օգտագործելու գաղափարը քննարկվեց նախկինում.

UTXO-սեթը կառուցված է թռիչքի ժամանակ, սկզբնական բլոկի ներբեռնման ժամանակ (IBD), պահվում է ամբողջությամբ և մշտապես, մինչդեռ դրա բովանդակությունը փոխվում է ցանցի յուրաքանչյուր նոր և ճիշտ բլոկի գործարքները մշակելուց հետո: Այս գործընթացը պահանջում է մոտավորապես 200 ԳԲ բլոկային տվյալների ներբեռնում և հարյուր միլիոնավոր թվային ստորագրությունների ստուգում: IBD գործընթացն ավարտվելուց հետո հիմնական գիծն այն է, որ UTXO-սեթը կզբաղեցնի մոտ 4 ԳԲ:

Այնուամենայնիվ, կուտակիչների դեպքում ֆոնդերի համար կոնսենսուսի կանոնները կրճատվում են մինչև գաղտնագրային ապացույցների ստուգում և առաջացում, և առկա միջոցներին հետևելու բեռը տեղափոխվում է այդ ֆոնդերի սեփականատիրոջ վրա, ով ապահովում է դրանց գոյության և սեփականության ապացույցը:

Կուտակիչը կարելի է անվանել հավաքածուի կոմպակտ ներկայացում: Պահված ներկայացման չափը պետք է լինի կամ հաստատուն , կամ ենթագծային մեծացնել՝ կապված հավաքածուի կարդինալության և բուն տարրի չափի հետ, օրինակ. , որտեղ n-ը պահված բազմության կարդինալությունն է:

Այս դեպքում կուտակիչը պետք է թույլ տա արտադրել հավաքածուի մեջ որևէ տարրի ընդգրկման ապացույց (ներառման ապացույց) և հնարավորություն ընձեռի արդյունավետորեն ստուգել այդ ապացույցը:

Մարտկոցը կոչվում է դինամիկ եթե թույլ է տալիս ավելացնել տարրեր և հեռացնել տարրեր հավաքածուից:

Նման մարտկոցի օրինակ կլինի RSA կուտակիչ, որն առաջարկվել է Boneh, Bunz, Fisch-ի կողմից 2018 թվականի դեկտեմբերին. Նման կուտակիչն ունի պահպանված ներկայացուցչության մշտական չափ, բայց պահանջում է ներկայություն ընդհանուր գաղտնիք (վստահելի կարգավորում): Այս պահանջը ժխտում է նման կուտակիչի կիրառելիությունը անվստահելի ցանցերի համար, ինչպիսին է Bitcoin-ը, քանի որ գաղտնի գեներացման ժամանակ տվյալների արտահոսքը կարող է հարձակվողներին թույլ տալ կեղծ ապացույցներ ստեղծել UTXO-ի գոյության մասին՝ խաբելով հանգույցները UTXO-կոմպլեկտով, որը հիմնված է նման կուտակիչի վրա:

Utreexo

Thaddeus Dryja-ի կողմից առաջարկված Utreexo դիզայնը հնարավորություն է տալիս ստեղծել դինամիկ կուտակիչ առանց վստահելի տեղադրում:

Utreexo-ն կատարյալ երկուականի անտառ է Մերկլի ծառեր և ներկայացված գաղափարների զարգացումն է Արդյունավետ ասինխրոն կուտակիչներ բաշխված pki-ի համար, ավելացնելով հավաքածուից տարրեր հեռացնելու հնարավորությունը:

Մարտկոցի տրամաբանական կառուցվածքը

Մարտկոցի բջիջները դասավորված են իդեալական երկուական ծառերի անտառում: Ծառերը դասավորված են ըստ բարձրության: Այս ներկայացումն ընտրվել է որպես առավել տեսողական և թույլ է տալիս պատկերացնել ծառերի միաձուլումը մարտկոցի վրա աշխատելու ընթացքում:

Հեղինակը նշում է, որ քանի որ անտառի բոլոր ծառերը իդեալական են, նրանց բարձրությունն արտահայտվում է երկուսի ուժով, ինչպես որ ցանկացած բնական թիվ կարող է ներկայացվել որպես երկուսի ուժերի գումար։ Համապատասխանաբար, տերևների ցանկացած հավաքածու կարելի է խմբավորել երկուական ծառերի մեջ, և բոլոր դեպքերում նոր տարր ավելացնելը գիտելիք է պահանջում։ միայն պահեստավորված ծառերի արմատային հանգույցների մասին.

Այսպիսով, Utreexo կուտակիչի պահպանված ներկայացումը արմատային հանգույցների ցանկն է (Merkle արմատ), և ոչ ամբողջ ծառերի անտառը.

Եկեք ներկայացնենք արմատային տարրերի ցանկը որպես Vec<Option<Hash>>. Ընտրովի տեսակ Option<Hash> ցույց է տալիս, որ արմատային տարրը կարող է բացակայել, ինչը նշանակում է, որ կուտակիչում համապատասխան բարձրությամբ ծառ չկա:

/// SHA-256 хеш
#[derive(Copy, Clone, Hash, Eq, PartialEq)]
pub struct Hash(pub [u8; 32]);

#[derive(Debug, Clone)]
pub struct Utreexo {
    pub roots: Vec<Option<Hash>>,
}

impl Utreexo {
    pub fn new(capacity: usize) -> Self {
        Utreexo {
            roots: vec![None; capacity],
        }
    }
}

Էլեմենտների ավելացում

Նախ, եկեք նկարագրենք գործառույթը parent(), որը ճանաչում է երկու տրված տարրերի մայր հանգույցը։

parent() ֆունկցիան

Քանի որ մենք օգտագործում ենք Merkle ծառերը, երկու հանգույցներից յուրաքանչյուրի մայրը մեկ հանգույց է, որը պահպանում է մանկական հանգույցների հեշերի միացման հեշը.

fn hash(bytes: &[u8]) -> Hash {
    let mut sha = Sha256::new();
    sha.input(bytes);
    let res = sha.result();
    let mut res_bytes = [0u8; 32];
    res_bytes.copy_from_slice(res.as_slice());

    Hash(res_bytes)
}

fn parent(left: &Hash, right: &Hash) -> Hash {
    let concat = left
        .0
        .into_iter()
        .chain(right.0.into_iter())
        .map(|b| *b)
        .collect::<Vec<_>>();

    hash(&concat[..])
}

Հեղինակը նշում է, որ Շառլ Բույագեի, Պիեռ-Ալեն Ֆուկեի, Ադի Շամիրի և Սեբաստիան Ցիմմերի կողմից նկարագրված հարձակումները կանխելու համար.
Երկրորդ պրեմիջային հարձակումը խճճված հեշ ֆունկցիաների վրա, բացի երկու հեշերից, շաղկապին պետք է ավելացնել նաև ծառի ներսում բարձրությունը։

Երբ դուք տարրեր եք ավելացնում կուտակիչին, դուք պետք է հետևեք, թե որ արմատային տարրերն են փոխվել: Հետևելով ձեր ավելացրած յուրաքանչյուր տարրի արմատային տարրերը փոխելու ճանապարհին, դուք կարող եք հետագայում կառուցել այդ տարրերի առկայության ապացույցը:

Հետևեք փոփոխություններին, երբ դրանք ավելացնեք

Կատարված փոփոխություններին հետևելու համար հայտարարենք կառուցվածքը Update, որը կպահի տվյալներ հանգույցների փոփոխությունների մասին։

#[derive(Debug)]
pub struct Update<'a> {
    pub utreexo: &'a mut Utreexo,
    // ProofStep хранит "соседа" элемента и его положение
    pub updated: HashMap<Hash, ProofStep>,
}

Մարտկոցին տարր ավելացնելու համար ձեզ հարկավոր է.

Ստեղծեք արմատային տարրերի զամբյուղների զանգված new_roots և այնտեղ տեղադրեք գոյություն ունեցող արմատային տարրերը՝ մեկական յուրաքանչյուր դույլի համար.

Code

let mut new_roots = Vec::new();

for root in self.roots.iter() {
    let mut vec = Vec::<Hash>::new();
    if let Some(hash) = root {
        vec.push(*hash);
    }

    new_roots.push(vec);
}

Ավելացրե՛ք ավելացվող տարրերը (զանգված insertions) առաջին սայլին new_roots[0]:

Code

new_roots[0].extend_from_slice(insertions);

Առաջին զամբյուղում ավելացված ապրանքները միացրեք մնացածի հետ.
- Մեկից ավելի ապրանքներով բոլոր սայլակների համար՝
  1. Զամբյուղի ծայրից վերցրեք երկու տարր, հաշվարկեք դրանց ծնողը, հեռացրեք երկու տարրերը
  2. Ավելացրեք հաշվարկված ծնողը հաջորդ զամբյուղին

Code

for i in 0..new_roots.len() {
    while new_roots[i].len() > 1 {
        // Объединяем два элемента в один и удаляем их
        let a = new_roots[i][new_roots[i].len() - 2];
        let b = new_roots[i][new_roots[i].len() - 1];
        new_roots[i].pop();
        new_roots[i].pop();
        let hash = self.parent(&a, &b);

        // Наращиваем количество корзин если требуется
        if new_roots.len() <= i + 1 {
            new_roots.push(vec![]);
        }

        // Помещаем элемент в следующую корзину
        new_roots[i + 1].push(hash);

        // Не забываем отслеживать изменения;
        // это пригодится для генерации доказательства добавления элементов
        updated.insert(a, ProofStep { hash: b, is_left: false });
        updated.insert(b, ProofStep {hash: a, is_left: true });
    }
}

Տեղափոխեք արմատային տարրերը աղբարկղերից ստացված կուտակիչ զանգված

Code

for (i, bucket) in new_roots.into_iter().enumerate() {
    // Наращиваем аккумулятор если требуется
    if self.roots.len() <= i {
        self.roots.push(None);
    }

    if bucket.is_empty() {
        self.roots[i] = None;
    } else {
        self.roots[i] = Some(bucket[0]);
    }
}

Ավելացված տարրերի համար ապացույցի ստեղծում

Մարտկոցի մեջ բջիջը ներառելու ապացույց (Proof) ծառայելու է որպես Մերկլի ուղի, որը բաղկացած է շղթայից ProofStep. Եթե ճանապարհը ոչ մի տեղ չի տանում, ապա ապացույցը սխալ է։

/// Единичный шаг на пути к элементу в дереве Меркла.
#[derive(Debug, Copy, Clone)]
pub struct ProofStep {
    pub hash: Hash,
    pub is_left: bool,
}

/// Доказательство включения элемента. Содержит сам элемент и путь к нему.
#[derive(Debug, Clone)]
pub struct Proof {
    pub steps: Vec<ProofStep>,
    pub leaf: Hash,
}

Ավելի վաղ ստացված տեղեկատվության օգտագործումը տարր ավելացնելիս (կառուցվածք Update), կարող եք ապացույց ստեղծել, որ մարտկոցին տարր է ավելացվել: Դա անելու համար մենք անցնում ենք կատարված փոփոխությունների աղյուսակը և յուրաքանչյուր քայլ ավելացնում ենք Մերկլի ճանապարհին, որը հետագայում որպես ապացույց կծառայի.

Code

impl<'a> Update<'a> {
    pub fn prove(&self, leaf: &Hash) -> Proof {
        let mut proof = Proof {
            steps: vec![],
            leaf: *leaf,
        };

        let mut item = *leaf;
        while let Some(s) = self.updated.get(&item) {
            proof.steps.push(*s);
            item = parent(&item, &s);
        }

        proof
    }
}

Ապացույց ստեղծելու գործընթացը

Ստուգելով ապացույցը տարրի համար

Տարրի ներառման ապացույցը ստուգելը հանգում է Մերկլի ուղուն հետևելուն, մինչև այն տանում է դեպի գոյություն ունեցող արմատային տարր.

pub fn verify(&self, proof: &Proof) -> bool {
    let n = proof.steps.len();
    if n >= self.roots.len() {
        return false;
    }

    let expected = self.roots[n];
    if let Some(expected) = expected {
        let mut current_parent = proof.leaf;
        for s in proof.steps.iter() {
            current_parent = if s.is_left {
                parent(&s.hash, &current_parent)
            } else {
                parent(&current_parent, &s.hash)
            };
        }

        current_parent == expected
    } else {
        false
    }
}

Տեսողական:

Ա.-ի համար ապացույցի ստուգման գործընթացը

Նյութերի հեռացում

Մարտկոցից բջիջը հեռացնելու համար դուք պետք է վավեր ապացույց ներկայացնեք, որ բջիջը այնտեղ է: Օգտագործելով ապացույցի տվյալները՝ հնարավոր է հաշվարկել կուտակիչի նոր արմատային տարրեր, որոնց համար տրված ապացույցն այլևս չի լինի ճշմարիտ։

Ալգորիթմը հետևյալն է.

Ինչպես հավելման դեպքում, մենք կազմակերպում ենք դատարկ զամբյուղների մի շարք, որոնք համապատասխանում են Մերկլի ծառերին, որոնց բարձրությունը հավասար է զամբյուղի ինդեքսից երկուսի հզորությանը:
Մենք զամբյուղների մեջ տեղադրում ենք տարրեր Մերկլի ճանապարհի աստիճաններից. զամբյուղի ինդեքսը հավասար է ընթացիկ քայլի թվին
Մենք հեռացնում ենք արմատային տարրը, որին տանում է ապացույցից ուղին
Ինչպես ավելացնելով, մենք հաշվարկում ենք նոր արմատային տարրերը՝ զույգերով միավորելով տարրերը զամբյուղներից և միավորման արդյունքը տեղափոխելով հաջորդ զամբյուղ։

Code

fn delete(&self, proof: &Proof, new_roots: &mut Vec<Vec<Hash>>) -> Result<(), ()> {
    if self.roots.len() < proof.steps.len() || self.roots.get(proof.steps.len()).is_none() {
        return Err(());
    }

    let mut height = 0;
    let mut hash = proof.leaf;
    let mut s;

    loop {
        if height < new_roots.len() {
            let (index, ok) = self.find_root(&hash, &new_roots[height]);
            if ok {
                // Remove hash from new_roots
                new_roots[height].remove(index);

                loop {
                    if height >= proof.steps.len() {
                        if !self.roots[height]
                            .and_then(|h| Some(h == hash))
                            .unwrap_or(false)
                        {
                            return Err(());
                        }

                        return Ok(());
                    }

                    s = proof.steps[height];
                    hash = self.parent(&hash, &s);
                    height += 1;
                }
            }
        }

        if height >= proof.steps.len() {
            return Err(());
        }

        while height > new_roots.len() {
            new_roots.push(vec![]);
        }

        s = proof.steps[height];
        new_roots[height].push(s.hash);
        hash = self.parent(&hash, &s);
        height += 1;
    }
}

«A» տարրի հեռացման գործընթացը.

Ինտեգրում գոյություն ունեցող ցանցին

Օգտագործելով առաջարկվող կուտակիչը՝ հանգույցները կարող են խուսափել DB-ի օգտագործումից՝ բոլոր UTXO-ները պահելու համար, մինչդեռ դեռ կարող են փոխել UTXO հավաքածուն: Սակայն ապացույցների հետ աշխատելու խնդիր է առաջանում։

Եկեք կանչենք վավերացնող հանգույցը, որն օգտագործում է UTXO կուտակիչը կոմպակտ (կոմպակտ վիճակի հանգույց), իսկ վավերացնողն առանց կուտակիչի է ամբողջական (լրիվ հանգույց): Երկու դասի հանգույցների առկայությունը խնդիր է ստեղծում դրանք մեկ ցանցում ինտեգրելու համար, քանի որ կոմպակտ հանգույցները պահանջում են UTXO-ների գոյության ապացույց, որոնք ծախսվում են գործարքների մեջ, մինչդեռ ամբողջական հանգույցները՝ ոչ: Եթե ցանցի բոլոր հանգույցները միաժամանակ և համակարգված կերպով չանցնեն Utreexo-ի օգտագործմանը, ապա կոմպակտ հանգույցները կմնան հետևում և չեն կարողանա գործել Bitcoin ցանցում:

Ցանցում կոմպակտ հանգույցների ինտեգրման խնդիրը լուծելու համար առաջարկվում է ներդնել հանգույցների լրացուցիչ դաս՝ կամուրջներ. Bridge հանգույցը ամբողջական հանգույց է, որը նաև պահում է Utreexo մարտկոցը և միացման ապացույցը Ամբողջ UTXO UTXO-սեթից: Կամուրջները հաշվարկում են նոր հեշեր և թարմացնում են կուտակիչն ու ապացույցները, երբ գալիս են գործարքների նոր բլոկներ: Կուտակիչի և ապացույցների պահպանումն ու թարմացումը նման հանգույցների վրա լրացուցիչ հաշվողական բեռ չի առաջացնում: Կամուրջները զոհաբերում են սկավառակի տարածությունը. անհրաժեշտ է ամեն ինչ կազմակերպել հեշերի համեմատ հեշեր կոմպակտ հանգույցների համար, որտեղ n-ը UTXO հավաքածուի հզորությունն է:

Ցանցի ճարտարապետություն

Կամուրջները հնարավորություն են տալիս աստիճանաբար ավելացնել կոմպակտ հանգույցներ ցանցին՝ առանց գոյություն ունեցող հանգույցների ծրագրային ապահովումը փոխելու։ Ամբողջական հանգույցները գործում են նախկինի պես՝ միմյանց միջև բաշխելով գործարքներն ու բլոկները: Bridge հանգույցները լիարժեք հանգույցներ են, որոնք լրացուցիչ պահում են Utreexo մարտկոցի տվյալները և ներառման ապացույցների մի շարք Ամբողջ UTXO-ն առայժմ: Կամուրջի հանգույցը չի գովազդում իրեն որպես այդպիսին, ձևացնելով, որ ամբողջական հանգույց է բոլոր ամբողջական հանգույցների համար և կոմպակտ հանգույց բոլոր կոմպակտ հանգույցների համար: Չնայած կամուրջները միացնում են երկու ցանցերը միասին, դրանք իրականում պետք է միացնեն դրանք միայն մեկ ուղղությամբ՝ գոյություն ունեցող ամբողջական հանգույցներից մինչև կոմպակտ հանգույցներ: Դա հնարավոր է, քանի որ գործարքի ձևաչափը փոփոխության կարիք չունի, և կոմպակտ հանգույցների UTXO ապացույցները կարող են հրաժարվել, այնպես որ ցանկացած կոմպակտ հանգույց կարող է նմանապես հեռարձակել գործարքները ցանցի բոլոր մասնակիցներին՝ առանց կամուրջ հանգույցների մասնակցության:

Ամփոփում

Մենք նայեցինք Utreexo մարտկոցը և ներդրեցինք նրա նախատիպը Rust-ում: Մենք դիտարկեցինք ցանցի ճարտարապետությունը, որը թույլ կտա ինտեգրվել մարտկոցի վրա հիմնված հանգույցներին: Կոմպակտ բռնումների առավելությունը պահվող տվյալների չափն է, որը լոգարիթմականորեն կախված է UTXO-ների հավաքածուի հզորությունից, ինչը մեծապես նվազեցնում է սկավառակի տարածության և նման հանգույցների պահեստավորման պահանջները: Թերությունը ապացույցների փոխանցման լրացուցիչ հանգույցների տրաֆիկն է, սակայն ապացույցների ագրեգացման տեխնիկան (երբ մեկ ապացույցն ապացուցում է մի քանի տարրերի առկայությունը) և քեշավորումը կարող են օգնել երթևեկությունը պահել ընդունելի սահմաններում:

Սայլակ:

Source: www.habr.com

Utreexo. սեղմում է բազմաթիվ UTXO Bitcoin

Ինչումն է խնդիրը?

UTXO և UTXO-set

Մարտկոցներ UTXO-ի համար

Utreexo

Մարտկոցի տրամաբանական կառուցվածքը

Էլեմենտների ավելացում

Ավելացված տարրերի համար ապացույցի ստեղծում

Ստուգելով ապացույցը տարրի համար

Նյութերի հեռացում

Ինտեգրում գոյություն ունեցող ցանցին

Ցանցի ճարտարապետություն

Ամփոփում

Добавить комментарий Չեղարկել պատասխանել