🥇 بلاڪ چين: پي او سي ٺاهڻ ۾ اسان کي ڪيترو خرچ ايندو؟

منهنجون اکيون ڊڄي رهيون آهن، پر منهنجا هٿ خارش ڪري رهيا آهن!

پوئين مضمونن ۾، اسان انهن ٽيڪنالاجين تي نظر وجهون جن تي بلاڪچين ٺهيل آهن (ڇا اسان کي بلاڪ چين ٺاهڻ گهرجي؟) ۽ ڪيس جيڪي انهن جي مدد سان لاڳو ڪري سگهجن ٿا (ڪيس ٺاهڻ ۾ اسان کي ڪيترو خرچ ايندو؟). اهو هٿ ۾ هٿ ملائڻ جو وقت آهي! پائلٽس ۽ پي او سي (تصور جو ثبوت) لاءِ، مان ڪلائوڊ استعمال ڪرڻ کي ترجيح ڏيان ٿو، ڇاڪاڻ ته اهو دنيا جي ڪنهن به هنڌ کان رسائي لائق آهي ۽ اڪثر ڪري ٿڪائيندڙ ماحول جي سيٽ اپ جي ضرورت کي ختم ڪري ٿو، ڇاڪاڻ ته اڳ ۾ ترتيب ڏنل ترتيبون موجود آهن. تنهن ڪري، اچو ته ڪجهه سادو ٺاهيون، جهڙوڪ شرڪت ڪندڙن جي وچ ۾ سڪن جي منتقلي لاءِ هڪ نيٽ ورڪ، ۽ اچو ته ان کي Citcoin سڏيون. اسان IBM ڪلائوڊ ۽ يونيورسل هائپرليجر فيبرڪ بلاڪچين استعمال ڪنداسين. پهرين، اچو ته سمجهون ته هائپرليجر فيبرڪ کي يونيورسل بلاڪچين ڇو سڏيو ويندو آهي.

هائپرليجر فيبرڪ - هڪ عالمگير بلاڪچين

عام طور تي، هڪ عالمگير معلوماتي نظام آهي:

سرورز جو هڪ سيٽ ۽ هڪ سافٽ ويئر ڪور جيڪو ڪاروباري منطق تي عمل ڪري ٿو؛
سسٽم سان رابطي لاءِ انٽرفيس؛
ڊوائيسز/ماڻهن جي رجسٽريشن، تصديق ۽ اختيار ڏيڻ جا ذريعا؛
هڪ ڊيٽابيس جيڪو آپريشنل ۽ آرڪائيو ڊيٽا محفوظ ڪري ٿو:

هائپرليجر فيبرڪ ڇا آهي ان جو سرڪاري نسخو هتي پڙهي سگهجي ٿو сайтеمختصر ۾، هائپرليجر فيبرڪ هڪ اوپن سورس پليٽ فارم آهي جيڪو پرائيويٽ بلاڪچين جي تعمير ۽ جاوا اسڪرپٽ ۽ گو ۾ لکيل ڪسٽم سمارٽ معاهدن جي عملدرآمد کي قابل بڻائي ٿو. اچو ته هائپرليجر فيبرڪ آرڪيٽيڪچر تي هڪ ويجهي نظر وجهون ۽ ڏسون ته اهو هڪ عالمگير نظام آهي، صرف ڊيٽا کي ذخيرو ڪرڻ ۽ رڪارڊ ڪرڻ لاءِ مخصوص گهرجن سان. اهي گهرجون آهن ته، سڀني بلاڪچين وانگر، ڊيٽا بلاڪ ۾ ذخيرو ٿيل آهي، جيڪي صرف بلاڪچين ۾ شامل ڪيا ويندا آهن جيڪڏهن شرڪت ڪندڙ اتفاق راءِ تي پهچي وڃن، ۽ هڪ ڀيرو لکڻ کان پوءِ، ڊيٽا کي ڳولي يا ختم نه ٿو ڪري سگهجي.

هائپرليجر فيبرڪ آرڪيٽيڪچر

ڊاگرام هائپرليجر فيبرڪ آرڪيٽيڪچر ڏيکاري ٿو:

تنظيمون — تنظيمن ۾ ساٿي شامل آهن، مطلب ته بلاڪچين تنظيمن جي مدد جي ڪري موجود آهي. مختلف تنظيمون هڪ ئي چينل جو حصو ٿي سگهن ٿيون.

چئنل — هڪ منطقي ڍانچو جيڪو ساٿين کي گروپن ۾ متحد ڪري ٿو، اهڙيءَ طرح هڪ بلاڪچين کي بيان ڪري ٿو. هائپرليجر فيبرڪ هڪ ئي وقت ڪيترن ئي بلاڪچين کي مختلف ڪاروباري منطق سان پروسيس ڪري سگهي ٿو.

ميمبرشپ سروسز فراهم ڪندڙ (MSP) — سڃاڻپ جاري ڪرڻ ۽ ڪردار تفويض ڪرڻ لاءِ هڪ CA (سرٽيفڪيٽ اٿارٽي) آهي. نوڊ ٺاهڻ لاءِ، توهان کي MSP سان رابطو ڪرڻو پوندو.

پير نوڊس — ٽرانزيڪشن جي تصديق ڪريو، بلاڪچين کي ذخيرو ڪريو، سمارٽ معاهدن تي عمل ڪريو، ۽ ايپليڪيشنن سان رابطو ڪريو. ساٿين وٽ MSP پاران جاري ڪيل هڪ سڃاڻپ (ڊجيٽل سرٽيفڪيٽ) آهي. Bitcoin يا Ethereum نيٽ ورڪن جي برعڪس، جتي سڀئي نوڊس برابر آهن، هائپرليجر فيبرڪ نوڊس ۾ مختلف ڪردار ادا ڪن ٿا:

ساٿي ٿي سگهي ٿو پير صاحب جي توثيق ڪندڙ (EP) ۽ سمارٽ معاهدن تي عمل ڪريو.
ڪميٽنگ پير (سي پي) - صرف بلاڪچين ۾ ڊيٽا ذخيرو ڪريو ۽ "ورلڊ اسٽيٽ" کي اپڊيٽ ڪريو.
اينڪر پير (اي پي) - جيڪڏهن ڪيتريون ئي تنظيمون بلاڪچين ۾ حصو وٺن ٿيون، ته اينڪر پيئرز کي انهن جي وچ ۾ رابطي لاءِ استعمال ڪيو ويندو آهي. هر تنظيم ۾ هڪ يا وڌيڪ اينڪر پيئرز هجڻ گهرجن. اي پي استعمال ڪندي، تنظيم ۾ ڪو به پيئر ٻين تنظيمن ۾ سڀني پيئرز بابت معلومات حاصل ڪري سگهي ٿو. اي پيز جي وچ ۾ معلومات کي هم وقت سازي ڪرڻ لاءِ، هڪ پيئر-ٽو-پيئر نيٽ ورڪ استعمال ڪيو ويندو آهي. گپ شپ پروٽوڪول.
اڳواڻ پير جيڪڏهن ڪنهن تنظيم ۾ ڪيترائي ساٿي آهن، ته صرف ليڊر پير آرڊرنگ سروس مان بلاڪ وصول ڪندو ۽ انهن کي ٻين ساٿين ۾ ورهائيندو. ليڊر کي يا ته جامد طور تي تفويض ڪري سگهجي ٿو يا تنظيم اندر ساٿين پاران متحرڪ طور تي چونڊيو وڃي ٿو. گپ شپ پروٽوڪول پڻ اڳواڻن بابت معلومات کي هم وقت سازي ڪرڻ لاءِ استعمال ڪيو ويندو آهي.

قيمتون — بلاڪچين ۾ ذخيرو ٿيل قدر جا ادارا. وڌيڪ خاص طور تي، اهي JSON فارميٽ ۾ اهم قدر ڊيٽا آهن. هي ڊيٽا "بلاڪچين" ۾ رڪارڊ ٿيل آهي. انهن جي هڪ تاريخ آهي، جيڪا بلاڪچين ۾ محفوظ ڪئي وئي آهي، ۽ هڪ موجوده حالت، جيڪا "ورلڊ اسٽيٽ" ڊيٽابيس ۾ محفوظ ڪئي وئي آهي. ڊيٽا جي جوڙجڪ ڪاروباري ضرورتن جي لحاظ کان من ماني طور تي آباد ڪئي وئي آهي. ڪو به گهربل فيلڊ نه آهي؛ صرف سفارش اها آهي ته اثاثن جو هڪ مالڪ هجڻ گهرجي ۽ قدر جي نمائندگي ڪن.

ليڊر — هڪ بلاڪچين ۽ هڪ ورلڊ اسٽيٽ ڊيٽابيس تي مشتمل آهي، جيڪو اثاثن جي موجوده حالت کي محفوظ ڪري ٿو. ورلڊ اسٽيٽ LevelDB يا CouchDB استعمال ڪري ٿو.

اسمارٽ معاهدو — سمارٽ معاهدا سسٽم جي ڪاروباري منطق کي لاڳو ڪن ٿا. هائپرليجر فيبرڪ ۾، سمارٽ معاهدن کي چين ڪوڊ سڏيو ويندو آهي. چين ڪوڊ اثاثن ۽ انهن ۾ شامل ٽرانزيڪشن کي بيان ڪرڻ لاءِ استعمال ڪيو ويندو آهي. ٽيڪنيڪل طور تي، سمارٽ معاهدا سافٽ ويئر ماڊل آهن جيڪي JS يا Go ۾ لاڳو ڪيا ويندا آهن.

تصديق جي پاليسي — هر چين ڪوڊ لاءِ، توهان پاليسيون مقرر ڪري سگهو ٿا ته ٽرانزيڪشن لاءِ ڪيترا ۽ ڪنهن کان تصديق جي اميد ڪجي. جيڪڏهن ڪا پاليسي مقرر نه ڪئي وئي آهي، ته ڊفالٽ "چينل ۾ ڪنهن به تنظيم جي ڪنهن به ميمبر طرفان ٽرانزيڪشن جي تصديق ٿيڻ گهرجي." مثال پاليسيون:

ٽرانزيڪشن جي تصديق تنظيم جي ڪنهن به منتظم طرفان ٿيڻ گهرجي؛
تنظيم جي ڪنهن به ميمبر يا گراهڪ طرفان تصديق ٿيل هجڻ گهرجي؛
ڪنهن به پير تنظيم طرفان تصديق ٿيل هجڻ گهرجي.

آرڊر سروس — ٽرانزيڪشن کي بلاڪن ۾ پيڪ ڪري ٿو ۽ انهن کي چينل ۾ ساٿين ڏانهن موڪلي ٿو. نيٽ ورڪ ۾ سڀني ساٿين تائين پيغام پهچائڻ جي ضمانت ڏئي ٿو. صنعتي نظامن لاءِ، اهو استعمال ڪيو ويندو آهي. ڪافڪا پيغام بروڪرترقي ۽ جانچ لاءِ ميرپور.

ڪال فلو

ايپليڪيشن Go، Node.js، يا Java SDK استعمال ڪندي Hyperledger Fabric سان رابطو ڪري ٿي؛
ڪلائنٽ هڪ ٽي ايڪس ٽرانزيڪشن ٺاهي ٿو ۽ ان کي تصديق ڪندڙ ساٿين ڏانهن موڪلي ٿو؛
پير ڪلائنٽ جي دستخط جي تصديق ڪري ٿو، ٽرانزيڪشن تي عمل ڪري ٿو، ۽ تصديق جي دستخط کي ڪلائنٽ ڏانهن واپس موڪلي ٿو. چين ڪوڊ صرف تصديق ڪندڙ پير تي عمل ڪيو ويندو آهي، ۽ نتيجو سڀني پيرز کي نشر ڪيو ويندو آهي. هن الگورتھم کي PBFT (عملي بازنطيني فالٽ برداشت ڪندڙ) اتفاق راءِ سڏيو ويندو آهي. اهو مختلف آهي ڪلاسيڪل BFT حقيقت اها آهي ته پيغام موڪليو ويو آهي ۽ تصديق سڀني شرڪت ڪندڙن کان نه، پر صرف هڪ خاص سيٽ کان متوقع آهي؛
ڪلائنٽ کي تصديق پاليسي سان لاڳاپيل جوابن جو تعداد ملڻ کان پوءِ، اهو آرڊرنگ سروس ڏانهن هڪ ٽرانزيڪشن موڪلي ٿو؛
آرڊرنگ سروس هڪ بلاڪ ٺاهيندي آهي ۽ ان کي سڀني ڪمٽمينٽ پيئرز ڏانهن موڪليندي آهي. آرڊرنگ سروس يقيني بڻائي ٿي ته بلاڪ ترتيب وار لکيا وڃن، جيڪو نام نهاد ليجر فورڪ کي ختم ڪري ٿو ("فورڪس" سيڪشن ڏسو);
ساٿي بلاڪ وصول ڪن ٿا، تصديق جي پاليسي کي ٻيهر چيڪ ڪن ٿا، بلاڪ کي بلاڪچين ۾ لکن ٿا، ۽ "ورلڊ اسٽيٽ" ڊي بي ۾ اسٽيٽ تبديل ڪن ٿا.

ان جي نتيجي ۾ نوڊس جي وچ ۾ ڪردارن جي ورڇ ٿيندي آهي. هي بلاڪچين جي اسڪيليبلٽي ۽ سيڪيورٽي کي يقيني بڻائي ٿو:

سمارٽ معاهدا (چين ڪوڊ) ساٿين جي توثيق ذريعي عمل ۾ آندا ويندا آهن. هي سمارٽ معاهدن جي رازداري کي يقيني بڻائي ٿو، ڇاڪاڻ ته ڪوڊ صرف ساٿين جي توثيق ذريعي محفوظ ڪيو ويندو آهي، سڀني شرڪت ڪندڙن طرفان نه.
آرڊرنگ تيز هجڻ گهرجي. اهو ان حقيقت سان يقيني بڻايو وڃي ٿو ته آرڊرنگ صرف هڪ بلاڪ ٺاهي ٿو ۽ ان کي ليڊر ساٿين جي هڪ مقرر سيٽ ڏانهن موڪلي ٿو.
ڪمٽمينٽ ڪندڙ ساٿي صرف بلاڪچين کي ذخيرو ڪندا آهن - انهن مان ڪيترائي ٿي سگهن ٿا ۽ انهن کي گهڻي طاقت يا فوري آپريشن جي ضرورت ناهي.

توهان هائپرليجر فيبرڪ جي آرڪيٽيڪچرل فيصلن بابت وڌيڪ سکي سگهو ٿا ۽ اهو ڇو ڪم ڪري ٿو جيئن اهو هتي ڪري ٿو: فن تعمير جي شروعات يا هتي: هائپرليجر فيبرڪ: اجازت ڏنل بلاڪچين لاءِ هڪ ورهايل آپريٽنگ سسٽم.

تنهن ڪري، هائپرليجر فيبرڪ هڪ واقعي عالمگير نظام آهي جيڪو توهان کي اجازت ڏئي ٿو:

سمارٽ ڪانٽريڪٽ ميڪانيزم استعمال ڪندي ڪسٽم ڪاروباري منطق لاڳو ڪريو؛
بلاڪچين ڊيٽابيس مان ڊيٽا JSON فارميٽ ۾ لکو ۽ حاصل ڪريو؛
سرٽيفڪيٽ اٿارٽي استعمال ڪندي API رسائي ڏيو ۽ تصديق ڪريو.

هاڻي جڏهن ته اسان هائپرليجر فيبرڪ جي ڪجهه خاصيتن کي ڍڪي ڇڏيو آهي، اچو ته آخرڪار ڪجهه مفيد ڪريون!

بلاڪچين کي استعمال ڪرڻ

مسئلو جي ترتيب

مقصد هيٺ ڏنل ڪمن سان هڪ Citcoin نيٽ ورڪ لاڳو ڪرڻ آهي: هڪ اڪائونٽ ٺاهيو، بيلنس حاصل ڪريو، هڪ اڪائونٽ ٽاپ اپ ڪريو، ۽ هڪ اڪائونٽ کان ٻئي اڪائونٽ ۾ سڪا منتقل ڪريو. اچو ته هڪ آبجيڪٽ ماڊل ٺاهيون، جيڪو پوءِ اسان هڪ سمارٽ ڪانٽريڪٽ ۾ لاڳو ڪنداسين. تنهن ڪري، اسان وٽ اڪائونٽ هوندا، نالن سان سڃاڻپ ٿيل ۽ هڪ بيلنس تي مشتمل، ۽ اڪائونٽس جي هڪ فهرست. اڪائونٽس ۽ اڪائونٽس جي فهرست هائپرليجر فيبرڪ جي اصطلاحن ۾ اثاثا آهن. مطابق، انهن جي هڪ تاريخ ۽ هڪ موجوده حالت آهي. مان هن کي بصري طور تي بيان ڪرڻ جي ڪوشش ڪندس:

مٿيان انگ اکر "ورلڊ اسٽيٽ" ڊيٽابيس ۾ ذخيرو ٿيل موجوده حالت جي نمائندگي ڪن ٿا. انهن جي هيٺان انگ اکر آهن جيڪي بلاڪچين ۾ ذخيرو ٿيل تاريخ ڏيکارين ٿا. اثاثن جي موجوده حالت ٽرانزيڪشن ذريعي تبديل ٿيندي آهي. هڪ اثاثو صرف مجموعي طور تي تبديل ٿيندو آهي، تنهنڪري ٽرانزيڪشن کي عمل ڪرڻ سان هڪ نئون اعتراض پيدا ٿئي ٿو، ۽ اثاثن جي موجوده قيمت تاريخ ۾ گم ٿي ويندي آهي.

آئي بي ايم ڪلائوڊ

۾ اڪائونٽ ٺاهيو IBM بادلبلاڪچين پليٽ فارم استعمال ڪرڻ لاءِ، توهان کي ان کي Pay-As-You-Go ۾ اپ گريڊ ڪرڻ جي ضرورت آهي. هي عمل وقت وٺندڙ ٿي سگهي ٿو، ڇاڪاڻ ته IBM اضافي معلومات جي درخواست ڪري ٿو ۽ ان کي دستي طور تي تصديق ڪري ٿو. مثبت پاسي تي، مان چئي سگهان ٿو ته IBM وٽ هائپرليجر فيبرڪ کي پنهنجي ڪلائوڊ ۾ تعینات ڪرڻ لاءِ سٺو تربيتي مواد آهي. مون کي مضمونن ۽ مثالن جي هيٺ ڏنل سيريز پسند آئي:

هيٺ IBM بلاڪچين پليٽ فارم جا اسڪرين شاٽ آهن. هي بلاڪچين ٺاهڻ لاءِ گائيڊ ناهي، پر ڪم جي دائري جو مظاهرو آهي. اسان جي مقصدن لاءِ، اسان هڪ واحد تنظيم ٺاهينداسين:

ان ۾ اسان نوڊس ٺاهيندا آهيون: آرڊرر CA، Org1 CA، Orderer Peer:

اسين استعمال ڪندڙ ٺاهيون ٿا:

اچو ته هڪ چينل ٺاهيون ۽ ان کي citcoin نالو ڏيون:

چينل بنيادي طور تي هڪ بلاڪچين آهي، تنهنڪري اهو بلاڪ زيرو (جينيسس بلاڪ) کان شروع ٿئي ٿو:

هڪ سمارٽ معاهدو لکڻ

/*
 * Citcoin smart-contract v1.5 for Hyperledger Fabric
 * (c) Alexey Sushkov, 2019
 */
 
'use strict';
 
const { Contract } = require('fabric-contract-api');
const maxAccounts = 5;
 
class CitcoinEvents extends Contract {
 
    async instantiate(ctx) {
        console.info('instantiate');
        let emptyList = [];
        await ctx.stub.putState('accounts', Buffer.from(JSON.stringify(emptyList)));
    }
    // Get all accounts
    async GetAccounts(ctx) {
        // Get account list:
        let accounts = '{}'
        let accountsData = await ctx.stub.getState('accounts');
        if (accountsData) {
            accounts = JSON.parse(accountsData.toString());
        } else {
            throw new Error('accounts not found');
        }
        return accountsData.toString()
    }
     // add a account object to the blockchain state identifited by their name
    async AddAccount(ctx, name, balance) {
        // this is account data:
        let account = {
            name: name,
            balance: Number(balance),       
            type: 'account',
        };
        // create account:
        await ctx.stub.putState(name, Buffer.from(JSON.stringify(account)));
 
        // Add account to list:
        let accountsData = await ctx.stub.getState('accounts');
        if (accountsData) {
            let accounts = JSON.parse(accountsData.toString());
            if (accounts.length < maxAccounts)
            {
                accounts.push(name);
                await ctx.stub.putState('accounts', Buffer.from(JSON.stringify(accounts)));
            } else {
                throw new Error('Max accounts number reached');
            }
        } else {
            throw new Error('accounts not found');
        }
        // return  object
        return JSON.stringify(account);
    }
    // Sends money from Account to Account
    async SendFrom(ctx, fromAccount, toAccount, value) {
        // get Account from
        let fromData = await ctx.stub.getState(fromAccount);
        let from;
        if (fromData) {
            from = JSON.parse(fromData.toString());
            if (from.type !== 'account') {
                throw new Error('wrong from type');
            }   
        } else {
            throw new Error('Accout from not found');
        }
        // get Account to
        let toData = await ctx.stub.getState(toAccount);
        let to;
        if (toData) {
            to = JSON.parse(toData.toString());
            if (to.type !== 'account') {
                throw new Error('wrong to type');
            }  
        } else {
            throw new Error('Accout to not found');
        }
 
        // update the balances
        if ((from.balance - Number(value)) >= 0 ) {
            from.balance -= Number(value);
            to.balance += Number(value);
        } else {
            throw new Error('From Account: not enought balance');          
        }
 
        await ctx.stub.putState(from.name, Buffer.from(JSON.stringify(from)));
        await ctx.stub.putState(to.name, Buffer.from(JSON.stringify(to)));
                 
        // define and set Event
        let Event = {
            type: "SendFrom",
            from: from.name,
            to: to.name,
            balanceFrom: from.balance,
            balanceTo: to.balance,
            value: value
        };
        await ctx.stub.setEvent('SendFrom', Buffer.from(JSON.stringify(Event)));
 
        // return to object
        return JSON.stringify(from);
    }
 
    // get the state from key
    async GetState(ctx, key) {
        let data = await ctx.stub.getState(key);
        let jsonData = JSON.parse(data.toString());
        return JSON.stringify(jsonData);
    }
    // GetBalance   
    async GetBalance(ctx, accountName) {
        let data = await ctx.stub.getState(accountName);
        let jsonData = JSON.parse(data.toString());
        return JSON.stringify(jsonData);
    }
     
    // Refill own balance
    async RefillBalance(ctx, toAccount, value) {
        // get Account to
        let toData = await ctx.stub.getState(toAccount);
        let to;
        if (toData) {
            to = JSON.parse(toData.toString());
            if (to.type !== 'account') {
                throw new Error('wrong to type');
            }  
        } else {
            throw new Error('Accout to not found');
        }
 
        // update the balance
        to.balance += Number(value);
        await ctx.stub.putState(to.name, Buffer.from(JSON.stringify(to)));
                 
        // define and set Event
        let Event = {
            type: "RefillBalance",
            to: to.name,
            balanceTo: to.balance,
            value: value
        };
        await ctx.stub.setEvent('RefillBalance', Buffer.from(JSON.stringify(Event)));
 
        // return to object
        return JSON.stringify(from);
    }
}
module.exports = CitcoinEvents;

وجداني طور تي، هتي هر شيءِ واضح هجڻ گهرجي:

ڪيترائي ڪم آهن (AddAccount، GetAccounts، SendFrom، GetBalance، RefillBalance) جيڪي ڊيمو پروگرام هائپرليجر فيبرڪ API استعمال ڪندي ڪال ڪندو.
SendFrom ۽ RefillBalance فنڪشن اهڙا واقعا پيدا ڪن ٿا جيڪي ڊيمو پروگرام وصول ڪندو.
جڏهن سمارٽ ڪانٽريڪٽ انسٽينٽيئيٽ ڪيو ويندو آهي ته انسٽينٽيئيٽ فنڪشن کي هڪ ڀيرو سڏيو ويندو آهي. حقيقت ۾، اهو صرف هڪ ڀيرو نه سڏيو ويندو آهي، پر هر ڀيري جڏهن سمارٽ ڪانٽريڪٽ ورجن تبديل ٿيندو آهي. تنهن ڪري، خالي صف سان لسٽ کي شروع ڪرڻ هڪ خراب خيال آهي، ڇاڪاڻ ته جڏهن به سمارٽ ڪانٽريڪٽ ورجن تبديل ٿيندو ته اسان موجوده لسٽ وڃائي ڇڏينداسين. پر اهو ٺيڪ آهي، مان صرف سکي رهيو آهيان.
اڪائونٽس ۽ اڪائونٽس جي فهرست JSON ڊيٽا اسٽرڪچر آهن. جاوا اسڪرپٽ ڊيٽا جي ڦيرڦار لاءِ استعمال ٿيندو آهي.
توهان getState فنڪشن کي ڪال ڪندي ڪنهن به اثاثن جي موجوده قيمت حاصل ڪري سگهو ٿا، ۽ ان کي putState استعمال ڪندي اپڊيٽ ڪري سگهو ٿا.
جڏهن ڪو اڪائونٽ ٺاهيو ويندو آهي، ته AddAccount فنڪشن سڏبو آهي، جيڪو بلاڪچين ۾ اڪائونٽس جي وڌ ۾ وڌ تعداد جو مقابلو ڪري ٿو (وڌ ۾ وڌ اڪائونٽس = 5). هتي هڪ بگ آهي (ڏٺو ويو؟) جيڪو اڪائونٽس جي تعداد ۾ لامحدود واڌ جو سبب بڻجي ٿو. اهڙين غلطين کان پاسو ڪرڻ گهرجي.

اڳيون، اسان چينل تي سمارٽ ڪانٽريڪٽ اپلوڊ ڪريون ٿا ۽ ان کي فوري طور تي شروع ڪريون ٿا:

اچو ته سمارٽ ڪانٽريڪٽ انسٽال ڪرڻ جي ٽرانزيڪشن تي نظر وجهون:

اسان جي چينل بابت وڌيڪ تفصيل ڏسو:

IBM ڪلائوڊ ۾ نتيجي ۾ بلاڪچين نيٽ ورڪ ڊاگرام هن ريت آهي. ڊاگرام ۾ Amazon ڪلائوڊ ۾ ورچوئل سرور تي هلندڙ هڪ ڊيمو پروگرام پڻ شامل آهي (ان بابت وڌيڪ ايندڙ حصي ۾):

هائپرليجر فيبرڪ API ڪالن لاءِ هڪ GUI ٺاهڻ

هائپرليجر فيبرڪ وٽ هڪ API آهي جيڪو استعمال ڪري سگهجي ٿو:

چينل ٺاهڻ؛
پيئر ٽو چينل ڪنيڪشن؛
هڪ چينل ۾ سمارٽ معاهدن کي انسٽال ڪرڻ ۽ انسٽنٽ ڪرڻ؛
ڪالنگ ٽرانزيڪشن؛
بلاڪچين ۾ معلومات جي درخواست ڪريو.

ايپليڪيشن ڊولپمينٽ

اسان جي ڊيمو پروگرام ۾، اسان صرف ٽرانزيڪشن شروع ڪرڻ ۽ معلومات جي درخواست ڪرڻ لاءِ API استعمال ڪنداسين، ڇاڪاڻ ته اسان IBM بلاڪچين پليٽ فارم استعمال ڪندي باقي مرحلا مڪمل ڪري چڪا آهيون. اسان هڪ معياري ٽيڪنالاجي اسٽيڪ استعمال ڪندي GUI لکنداسين: Express.js + Vue.js + Node.js. جديد ويب ايپليڪيشنون ٺاهڻ ڪيئن شروع ڪجي ان بابت هڪ الڳ مضمون لکي سگهجي ٿو. هتي ليڪچر سيريز جو لنڪ آهي جيڪو مون کي تمام گهڻو پسند آيو: Vue.js ۽ Express.js استعمال ڪندي مڪمل اسٽيڪ ويب ايپنتيجو هڪ ڪلائنٽ-سرور ايپليڪيشن آهي جنهن ۾ گوگل جي مٽيريل ڊيزائن جي انداز ۾ هڪ واقف گرافڪ انٽرفيس آهي. ڪلائنٽ ۽ سرور جي وچ ۾ REST API ڪيترن ئي ڪالن تي مشتمل آهي:

هائپرليجر ڊيمو/v1/init — بلاڪچين کي شروع ڪريو؛
هائپرليجر ڊيمو/v1/اڪائونٽس/لسٽ — سڀني اڪائونٽس جي فهرست حاصل ڪريو؛
هائپرليجر ڊيمو/v1/اڪائونٽ؟ نالو=باب ۽ بيلنس=100 - باب اڪائونٽ ٺاهيو؛
هائپرليجر ڊيمو/v1/info?account=Bob — باب اڪائونٽ بابت معلومات حاصل ڪريو؛
هائپرليجر ڊيمو/v1/ٽرانزيڪشن؟from=Bob&to=Alice&volume=2 — باب کان ايلس ڏانهن ٻه سڪا منتقل ڪريو؛
هائپرليجر ڊيمو/v1/ڊسڪنيڪٽ — بلاڪچين سان ڪنيڪشن بند ڪريو.

API جي وضاحت مثالن سان گڏ پوسٽ ڪئي وئي آهي پوسٽ مين ويب سائيٽ — HTTP APIs جي جانچ لاءِ هڪ مشهور پروگرام.

ايميزون ڪلائوڊ ۾ ڊيمو ايپليڪيشن

مون ايپ کي Amazon تي اپلوڊ ڪيو ڇاڪاڻ ته IBM اڃا تائين منهنجي اڪائونٽ کي اپ گريڊ نه ڪري سگهيو آهي ۽ مون کي ورچوئل سرور ٺاهڻ جي اجازت نه ڏني آهي. مون مٿي چيري طور هڪ ڊومين شامل ڪيو: www.citcoin.infoمان سرور کي ڪجهه دير لاءِ هلائيندس، پوءِ ان کي بند ڪري ڇڏيندس، ڇاڪاڻ ته ڪرائي تي ڪمائي اچي رهي آهي، ۽ Citcoin اڃا تائين ايڪسچينج تي لسٽ ٿيل ناهي. مان آرٽيڪل ۾ ڊيمو اسڪرين شاٽ شامل ڪري رهيو آهيان ته جيئن منطق واضح هجي. ڊيمو ايپ ڪري سگهي ٿي:

بلاڪچين کي شروع ڪريو؛
هڪ اڪائونٽ ٺاهيو (پر هاڻي نئون اڪائونٽ ٺاهڻ ممڪن ناهي، ڇاڪاڻ ته بلاڪچين سمارٽ ڪانٽريڪٽ ۾ بيان ڪيل اڪائونٽن جي وڌ ۾ وڌ تعداد تائين پهچي چڪو آهي)؛
اڪائونٽس جي فهرست حاصل ڪريو؛
ايلس، باب ۽ ايلڪس جي وچ ۾ سِٽ ڪوئن سڪا منتقل ڪريو؛
واقعا وصول ڪريو (پر في الحال واقعا ڏيکارڻ جو ڪو طريقو ناهي، تنهن ڪري سادگي لاءِ انٽرفيس ٻڌائي ٿو ته واقعا سپورٽ نه آهن)؛
لاگ ڪارناما.

پهرين، اچو ته بلاڪچين کي شروع ڪريون:

پوءِ، پنهنجو اڪائونٽ ٺاهيو ۽ بيلنس سان پنهنجو وقت ضايع نه ڪريو:

اسان کي سڀني موجود اڪائونٽس جي فهرست ملي ٿي:

موڪليندڙ ۽ وصول ڪندڙ کي چونڊيو ۽ انهن جا بيلنس حاصل ڪريو. جيڪڏهن موڪليندڙ ۽ وصول ڪندڙ هڪجهڙا آهن، ته انهن جو اڪائونٽ ٽاپ اپ ڪيو ويندو:

اسان لاگ ۾ ٽرانزيڪشن جي عملدرآمد جي نگراني ڪريون ٿا:

ڊيمو پروگرام لاءِ بس اهو ئي آهي. اڳيون، توهان بلاڪچين تي اسان جي ٽرانزيڪشن ڏسي سگهو ٿا:

۽ ٽرانزيڪشن جي عام فهرست:

اسان ڪاميابي سان Citcoin نيٽ ورڪ PoC مڪمل ڪيو آهي. Citcoin کي سڪن جي منتقلي لاءِ هڪ مڪمل نيٽ ورڪ بڻائڻ لاءِ ٻيو ڇا ڪرڻ جي ضرورت آهي؟ ٿورو:

اڪائونٽ ٺاهڻ جي مرحلي تي، پرائيويٽ/پبلڪ ڪي جنريشن لاڳو ڪريو. پرائيويٽ ڪي اڪائونٽ استعمال ڪندڙ کي محفوظ ڪرڻ گهرجي، ۽ پبلڪ ڪي بلاڪچين تي محفوظ ڪرڻ گهرجي.
هڪ سڪي جي منتقلي ڪريو جيڪا استعمال ڪندڙ جي سڃاڻپ لاءِ نالي جي بدران عوامي ڪي استعمال ڪري.
صارف کان سرور ڏانهن ويندڙ ٽرانزيڪشن کي سندس پرائيويٽ ڪي سان انڪرپٽ ڪريو.

ٿڪل

اسان Citcoin نيٽ ورڪ کي هيٺ ڏنل خاصيتن سان لاڳو ڪيو آهي: هڪ اڪائونٽ شامل ڪريو، پنهنجو بيلنس حاصل ڪريو، پنهنجو اڪائونٽ ٽاپ اپ ڪريو، ۽ هڪ اڪائونٽ کان ٻئي اڪائونٽ ۾ سڪا منتقل ڪريو. تنهن ڪري، PoC ٺاهڻ ۾ اسان کي ڪيترو خرچ آيو؟

عام طور تي بلاڪچين ۽ خاص طور تي هائپرليجر فيبرڪ جو مطالعو ڪرڻ ضروري آهي؛
IBM يا Amazon ڪلائوڊ استعمال ڪرڻ سکو؛
JS پروگرامنگ ٻولي ۽ ڪجهه ويب فريم ورڪ سکو؛
جيڪڏهن ڪجهه ڊيٽا کي بلاڪچين ۾ نه پر هڪ الڳ ڊيٽابيس ۾ محفوظ ڪرڻ جي ضرورت آهي، ته پوءِ سکو ته ڪيئن ضم ڪجي، مثال طور، PostgreSQL؛
۽ آخري پر گهٽ ۾ گهٽ نه، توهان لينڪس کي ڄاڻڻ کان سواءِ جديد دنيا ۾ ڪٿي به نه ٿا پهچي سگهو!

اهو راڪيٽ سائنس ناهي، پر توهان کي سخت محنت ڪرڻي پوندي!

GitHub تي ذريعن

مون ذريعا رکيا GitHubذخيري جي مختصر وضاحت:
ڪيٽلاگ «سرور" — Node.js سرور
ڪيٽلاگ «مختاران مائي" — Node.js ڪلائنٽ
ڪيٽلاگ «blockchain» (پيراميٽر ويليوز ۽ ڪيز، يقيناً، ڪم نه ڪري رهيا آهن ۽ صرف مثال جي مقصدن لاءِ ڏنل آهن):

معاهدو - سمارٽ معاهدي جو سورس ڪوڊ
والٽ — هائپرليجر فيبرڪ API استعمال ڪرڻ لاءِ استعمال ڪندڙ ڪيز.
*.cds — سمارٽ معاهدن جا مرتب ڪيل نسخا
*.json فائلون - هائپرليجر فيبرڪ API استعمال ڪرڻ لاءِ مثال ترتيب ڏيڻ واريون فائلون

هي صرف شروعات آهي!

جو ذريعو: www.habr.com