استفاده از blockchain Ethereum برای ذخیره و پرس و جو از داده های فارماکوژنومیک از طریق قراردادهای هوشمند

از آنجا که داده های فارماکوژنومیک به طور فزاینده ای در تصمیمات درمانی بالینی یکپارچه می شوند ، نیاز به ذخیره سازی داده های مناسب و به اشتراک گذاری پروتکل ها باید اتخاذ شود. یکی از گزینه های امیدوار کننده برای ذخیره سازی امن و یکپارچگی بالا ، قراردادهای هوشمند Ethereum است. Ethereum یک بستر blockchain است ، و قراردادهای هوشمند قطعات غیرقابل تغییر کد هستند که در این پلتفرم روی ماشین های مجازی کار می کنند که توسط یک کاربر یا یک قرارداد دیگر (در شبکه blockchain) قابل استفاده است. رقابت IDASH 2019 (ادغام داده ها برای تجزیه و تحلیل ، ناشناس سازی و اشتراک گذاری) برای تجزیه و تحلیل ژنوم ایمن ، شرکت کنندگان را به چالش کشید تا قراردادهای هوشمند اتریوم زمان و فضا را برای داده های روابط ژن و دارویی توسعه دهند.

مواد و روش ها

در اینجا ما یک قرارداد هوشمند خاص برای ذخیره و پرس و جو از تعامل ژن و دارو در اتریوم با استفاده از یک رویکرد چند نقشه برداری مبتنی بر شاخص طراحی می کنیم. قرارداد ما هر مشاهده فارماکوژنومیک را ذخیره می کند ، یک سه گانه ژن-متمایز با نتیجه ، در نقشه برداری قابل جستجو توسط یک شناسه منحصر به فرد ، امکان ذخیره سازی و پرس و جو کارآمد را فراهم می کند. این راه حل در مسابقات برتر IDASH 2019 در رده های برتر قرار گرفت. ما بیشتر "راه حل چالش" خود را بهبود می بخشیم و یک قرارداد هوشمند "FastQuery" جایگزین "FastQuery" ایجاد می کنیم ، که ترکیبات یکسان ژن-وارانت-دارو را در یک ورودی ذخیره سازی واحد ترکیب می کند و منجر به مقیاس پذیری قابل توجهی بهتر و کارآیی پرس و جو می شود.

نتایج

نتیجه

ما نشان می دهیم که داده های فارماکوژنومیک می توانند با استفاده از blockchain اتریوم ذخیره و پرس و جو شوند. راه حل های ما به طور بالقوه می تواند برای ذخیره طیف وسیعی از داده های بالینی مورد استفاده قرار گیرد و به سایر زمینه هایی که نیاز به ذخیره داده های یکپارچگی بالا و دسترسی کارآمد دارند ، گسترش یابد.

زمینه

داده های فارماکوژنومیک ، که نتایج برهم کنش های خاص ژن و دارو را توصیف می کند ، به محققان و پزشکان این امکان را می دهد تا پیش بینی کنند که چگونه بیماران خاص بر اساس انواع ژنتیکی مورد نظر خود به یک داروی معین پاسخ می دهند. به عنوان مثال ، یک بیمار ممکن است بیشتر مستعد اثرات سمی از یک دارو باشد زیرا آنها دارای یک نوع هستند که توانایی آنها در پاکسازی دارو را محدود می کند و بنابراین باید یک جایگزین تجویز شود. کلینیک مایو شامل گنجاندن داده های فارماکوژنومیک در نمودار بیمار به "باند هشدار پزشکی چشمک زن ،" است که دلالت بر این دارد که این داده ها ممکن است در مراقبت های اساسی پزشکی به عنوان مچ بند نشان دهنده آلرژی بیمار یا خطر سقوط باشد. با توجه به اعتماد به نفس فزاینده به این داده ها برای معالجه پزشکی ، فساد یا از دست دادن آن ، اعم از عمدی یا تصادفی ، این پتانسیل را دارد که مستقیماً روی درمان های پزشکی تأثیر بگذارد. بنابراین این جوهر است که یک روش قوی برای ذخیره ، به اشتراک گذاری و به روزرسانی پایگاه داده های فارماکوژنومیک به روشی ایمن و یکپارچه سازی بالا تهیه شود.

اهمیت ذخیره ایمن داده های ژنومی شخصی برای محافظت از حریم شخصی شخصی به طور گسترده ای ذکر شده است [2]. داده های فارماکوژنومیک نگرانی های مشابهی را برای حفظ حریم خصوصی و تغییر ناپذیری ارائه می دهد. برای هر دو ژنومیک و فارماکوژنومیک ، یکپارچگی داده ها بسیار مهم است ، زیرا از دست دادن ، فساد یا تغییر داده ها می تواند اثرات مشکل ساز داشته باشد (در مورد ژنومیک ، تشخیص اشتباه و در فارماکوژنومیک ، تجویز داروی اشتباه). بنابراین ، هر روشی برای ذخیره و به اشتراک گذاری داده های فارماکوژنومیک باید مانع از بین رفتن ، تغییر یا خراب شدن آن شود. تعادل بین دسترسی و حریم خصوصی نیز برای هر دو نوع داده مهم است. محققان و پزشکان باید بدون نشت اطلاعات خصوصی در مورد بیماران خود بتوانند به داده های ژنومی دسترسی پیدا کنند. آنها همچنین باید بتوانند داده های تعامل ژن و دارو را در مراحل آزمایش بالینی ذخیره و به اشتراک بگذارند ، ضمن اینکه به پروتکل اختصاصی (یعنی در یک شرکت دارویی) احترام می گذارند یا به سادگی با سایر گروه هایی که در این مطالعه نقش دارند (یعنی در داخل یا بین مؤسسات دانشگاهی) به اشتراک می گذارند. این الزامات از توسعه راه حل های خلاق به منظور تضمین پایگاه داده های ایمن و قوی فارماکوژنومیک دعوت می کنند.

فناوری blockchain به دلیل عدم تمرکز ، معماری توزیع شده و تغییر ناپذیری ، برای حل مشکلات ذخیره سازی داده ها در حال افزایش است. عدم تمرکز مانع از کنترل هر کاربر واحد می شود. معماری توزیع شده نقطه واحد شکست را از بین می برد. و تغییر ناپذیری از تغییر سوابق گذشته جلوگیری می کند. با توجه به الزامات ذخیره داده های فارماکوژنومیک که در بالا مورد بحث قرار گرفت ، فناوری blockchain یک اجرای ایده آل است. برخی معتقدند که blockchain یک فن آوری است و برای حل مشکلاتی که سایر فن آوری های ساده تر می توانند حل کنند ، یعنی یک بانک اطلاعاتی توزیع شده استفاده می شود [3]. با این حال ، طبق گفته کوو و همکاران.["blockchain فن آوری های لجر توزیع شده برای برنامه های زیست پزشکی و مراقبت های بهداشتی ،" جامیا ، 2017] ، blockchain ویژگی هایی را ارائه می دهد که بانکهای اطلاعاتی توزیع شده ، از جمله مدیریت غیرمتمرکز ، یک دنباله حسابرسی غیرقابل تغییر ، پیشرفت داده ها ، استحکام و در دسترس بودن و امنیت و حریم خصوصی است. این مزایای کلیدی باعث می شود blockchain برای برنامه های زیست پزشکی بهتر از سایر سیستم های مدیریت پایگاه داده توزیع شده مناسب تر باشد [4].

blockchain یک دفترچه دیجیتال غیر متمرکز ، توزیع شده و قابل مقایسه با یک لیست فقط ضمیمه است که توسط هش های رمزنگاری مرتبط است [5]. دفترچه در یک شبکه "همتا به همسالان" به اشتراک گذاشته شده است. هر گره در شبکه کپی از لیست را در رایانه خود نگه می دارد که همگام سازی با بقیه شبکه است. گره های موجود در شبکه معاملات را ارسال می کنند ، که ممکن است در یک بلوک جدید تأیید و به زنجیره اضافه شود. هر بلوک دارای هش از محتویات خود و هش بلوک قبلی است. بنابراین ، نمی توان رکورد را تغییر داد ، زیرا حتی کوچکترین تغییر باعث تغییر چشمگیر هش بلوک پایین دست می شود. ساختار داده blockchain برای اولین بار در سال 2008 توسط Satoshi Nakamoto (نام مستعار) به عنوان یک دفترچه دیجیتال برای معاملات بیت کوین ، یک رمزنگاری در حال حاضر بدنام معرفی شد [5]. با این حال ، از آنجا که این فناوری blockchain برنامه اولیه به یک فناوری متنوع تر و پویا تبدیل شده است ، که اکنون برای کارهای مختلف از ردیابی توزیع مواد غذایی تا پخش موسیقی استفاده می شود [6 ، 7].

blockchain به دلیل شفافیت ، تغییر ناپذیری ، امنیت ، حریم خصوصی و تفکیک آن به طور فزاینده ای برای حل مشکلات دنیای واقعی اعمال می شود. برای دستیابی به شفافیت ، هر معامله در زنجیره برای سایر کاربران شبکه پخش می شود که معاملات را معدن و تأیید می کنند. تغییر ناپذیری به این دلیل بوجود می آید که هر بلوک حاوی هش کلیه محتویات موجود در بلوک قبلی است و از هرگونه تغییر در معاملات گذشته جلوگیری می کند. امنیت از طریق معماری توزیع شده حاصل می شود. تاریخچه معاملات و داده های ذخیره شده در زنجیره در بسیاری از گره های شبکه توزیع می شود ، بنابراین هیچ نقطه ای از خرابی وجود ندارد. حریم شخصی کاربر حداقل در یک شبکه عمومی blockchain حفظ می شود ، زیرا کاربران می توانند ناشناس باشند و فقط با آدرس کیف پول خود قابل شناسایی باشند. این فناوری همچنین نیاز به یک مرد میانه مانند بانک یا پلت فرم پخش موسیقی را از بین می برد و به کاربران امکان می دهد مستقیماً با سایر کاربران معامله کنند زیرا نیازی به اعتماد به شبکه نیست [5].

بسیاری از برنامه های blockchain امروز برای اجرای در اتریوم ساخته شده اند. Ethereum یک دستگاه دولتی مبتنی بر معامله است که اصلاحاتی را در حالت خود در یک blockchain وارد می کند. این دستگاه اجازه می دهد تا برنامه های طراحی شده برای blockchain های دولتی و خصوصی از طریق "قراردادهای هوشمند" [8]. قراردادهای هوشمند قطعاتی از کدهای قابل اجتناب هستند که در حالت اتریوم زندگی می کنند و معاملات را هنگام فراخوانی توسط کاربر یا یک قرارداد هوشمند دیگر انجام می دهند [9]. در حالی که معاملات در سایر محیط های blockchain ، مانند بیت کوین ، به دلیل پیکربندی حالت شبکه و زبان برنامه نویسی مورد استفاده در پیچیدگی آنها محدود بود ، قراردادهای هوشمند به زبانهای تورینگ کامل مانند استحکام ، یک زبان شی گرا تحت تأثیر Javascript ، C ++ برنامه ریزی می شوند.، پایتون ، و پاورشل [10]. قراردادهای هوشمند شفافیت را ارائه می دهند (کاربران می توانند تأیید کنند که چه کسی برنامه را مستقر کرده و اطمینان حاصل می کند که از نسخه صحیح برنامه استفاده می کنند) و تغییر ناپذیری (این برنامه نمی تواند تغییر یابد و نسخه های جدید برنامه برای همه کاربران قابل دسترسی است). یک نمونه مشترک از یک قرارداد هوشمند ، مواردی است که به شهروندان اجازه می دهد تا در انتخابات به طور ایمن رأی دهند [11]. با این وجود ، پتانسیل قابل توجهی برای استفاده از قراردادهای هوشمند برای انجام معاملات در زمینه ها و صنایع مختلف وجود دارد.

برای رقابت IDASH 2019 ، ما قصد داشتیم یک قرارداد هوشمند Ethereum برای ذخیره و پرس و جو از داده های فارماکوژنومیک با بهره وری زمان و حافظه ایجاد کنیم. در حالی که فناوری blockchain چندین ویژگی مفید را ارائه می دهد ، در هنگام ذخیره و پرس و جو داده ها ، بسیار ناکارآمد و کند است [5]. بنابراین ، استفاده از آن برای برنامه های روزمره چالش برانگیز است. علاوه بر این ، توسعه و استقرار قراردادهای هوشمند نیاز به فرمان زبان برنامه نویسی استحکام ، که دارای بسیاری از مناطق مختلف است ، و کار با API Ethereum به طور مداوم در حال تحول است. با این حال ، ما به این چالش های طراحی و لجستیکی پرداختیم و یک ساختار داده مبتنی بر شاخص و چند نقشه برداری را در یک قرارداد هوشمند استحکام برای ذخیره داده ها ارائه دادیم. به طور خاص ، ما هر مشاهده فارماکوژنومیک را در نقشه برداری قابل جستجو توسط یک شناسه عدد صحیح منحصر به فرد ذخیره می کنیم. سپس ما سه نقشه برداری اضافی را نگه می داریم که به ترتیب شناسه های منحصر به فرد با نام ژن ، شماره نوع و نام دارو را ذخیره می کنند. این طرح برای قرار دادن داده های کارآمد زمان و حافظه و پرس و جو توسط یک تا سه قسمت امکان پذیر است. به خاطر مقیاس پذیری ، ما یک راه حل متفاوتی که به عنوان FastQuery گفته می شود ، تهیه کردیم. در این راه حل ، ما داده ها را برای هر ترکیب منحصر به فرد ژن-وارانت-دارو به عنوان یک ورودی واحد در ذخیره سازی ذخیره می کنیم. این امر نیاز به جمع آوری داده ها را از چندین مکان در ذخیره سازی هنگام پرس و جو از بین برد. این راه حل FastQuery به طور قابل توجهی باعث افزایش بازده زمان برای پرس و جو توسط یک تا سه زمینه شد.

مواد و روش ها

در این مطالعه ما یک ساختار داده و الگوریتم های کارآمد زمان/فضا را برای ذخیره و پرس و جو فارماکوژنومیک در یک قرارداد هوشمند در یک blockchain خصوصی Ethereum طراحی کرده ایم. داده ها در یک شبکه کوچک blockchain با تنها چهار گره ذخیره شد. هر نقطه داده به عنوان یک معامله واحد به قرارداد هوشمند ما درج شد. تمام داده ها باید در زنجیره ای ذخیره شوند. هیچ ذخیره سازی داده های خارج از زنجیره مجاز نبود.

فناوری blockchain توضیح داده شده است

در اینجا ما یک آغازگر در مورد فناوری blockchain برای کسانی که با اصول اولیه ناآشنا هستند ارائه می دهیم. برای درمان دقیق تر این ماده ، خواننده باید با کاغذ سفید بیت کوین و کاغذ زرد اتریوم مشورت کند [5 ، 8].

همانطور که در ابتدا بیان شد ، یک blockchain یک ساختار داده ایمن است که در یک شبکه همتا به همتا به اشتراک گذاشته شده است [شکل. 1A-B]. این زنجیره از بلوک های داده های مرتبط با هش ها تشکیل شده است. هر بلوک در زنجیره حاوی یک هدر و لیستی از معاملات معتبر است. این هدر شامل چندین زمینه مربوط به یکپارچگی ساختار داده (به عنوان مثال زمان سنج) و پارامترهای شبکه (به عنوان مثال پارامترهای معدن) است. این زمینه ها شامل زمان سنج بلوک ، شماره بلوک ، پارامترهای معدن و هش محتوای بلوک قبلی (که یک بلوک را به قسمت بعدی پیوند می دهد) شامل می شود. کاربران یا گره ها می توانند معاملات را که وضعیت شبکه را تغییر می دهد ، به عنوان مثال با ارسال مقدار از یک آدرس کاربر به دیگری یا ذخیره یک مقدار در یک قرارداد هوشمند (که در زیر در زیر بحث شده است) ارسال کنند.

قراردادهای Blockchain و Smart Ethereum. یک شبکه blockchain شامل یک دفترچه دیجیتال غیر متمرکز و توزیع شده است که به صورت همسالان به اشتراک گذاشته شده است. شماتیک شبکه که در اینجا نشان داده شده است شامل چهار گره (رایانه) است که هر کدام یک نسخه از زنجیره را همگام سازی می کنند. این شبکه غیر متمرکز است (نقطه کنترل مرکزی وجود ندارد) و توزیع می شود (زنجیره ای در چندین مکان فیزیکی ذخیره می شود). b یک blockchain را می توان به عنوان رشته ای از بلوک های مرتبط با هش رمزنگاری مشاهده کرد. یعنی محتوای هر بلوک شامل هش از محتوای بلوک قبلی است. بلوک ها همچنین حاوی داده هایی در مورد وضعیت شبکه ذخیره شده در ریشه Trie هستند. ساختار داده های دولت در Ethereum اطلاعات را برای حساب های کاربر و قرارداد هوشمند ذخیره می کند. c کد برای یک قرارداد هوشمند خاص در یک آدرس در ذخیره سازی شبکه قرار دارد ، و همچنین ذخیره سازی خاص خود را حفظ می کند (برای مثال برای ذخیره متغیرها). در اینجا ما یک نمودار جریان را نشان می دهیم که الگوریتم های درج و پرس و جو را در قرارداد هوشمند راه حل چالش ما نشان می دهد

مکانیسم توافق شبکه تعیین می کند که کدام کاربر در شبکه تراکنش ها را به عنوان یک بلوک جدید به زنجیره اضافه می کند. این یک فرآیند حیاتی است. اگر شکست بخورد، اعتبار بلوک اضافه شده به خطر می افتد. برجسته‌ترین مکانیسم‌های اجماع شامل اثبات کار، اثبات سهام و اثبات قدرت است. در شبکه اثبات کار (PoW)، گره‌ها بلوک می‌کنند. یعنی انرژی محاسباتی را برای شناسایی مقادیری اعمال می‌کنند که وقتی به محتویات بلوک ورودی اضافه می‌شوند، هش بلوکی کمتر از پارامتر شبکه مجموعه‌ای که به آن مشکل گفته می‌شود، به دست می‌آید. دشواری یک پارامتر در سطح شبکه است که می تواند به منظور تنظیم سرعت تشکیل بلوک تغییر کند. مکانیسم اثبات کار برای شبکه‌های بلاک چین ارزهای دیجیتال عمومی مانند بیت‌کوین بسیار مهم است، زیرا هزینه‌ای را برای اصلاح بلاک چین تعیین می‌کند و در نتیجه بازیگران بد را از خراب کردن زنجیره باز می‌دارد [5]. بسیاری از مکانیسم PoW به دلیل ناپایداری در دراز مدت به دلیل مقادیر زیادی انرژی مورد نیاز برای انجام استخراج محاسباتی انتقاد کرده اند [12]. برای پرداختن به این انتقاد، مکانیسم اثبات سهام پیشنهاد شده است [13]. با اثبات سهام، یک الگوریتم شبکه تعیین می کند که کدام گره بلوک را بر اساس سهام گره، ترکیبی از پارامترها از جمله مانده حساب آنها، به زنجیره اضافه می کند [14]. مکانیسم PoS به محاسبات سنگین نیاز ندارد، در نتیجه مصرف انرژی در شبکه را کاهش می دهد. این مکانیسم های اجماع برای یک شبکه بلاک چین عمومی که در آن هر کسی در جهان می تواند یک گره را اجرا کند و به طور بالقوه زنجیره را تغییر دهد، ضروری است. با این حال، در یک شبکه خصوصی و دارای مجوز، این مکانیسم‌ها را می‌توان با یک مکانیسم اثبات اقتدار ساده جایگزین کرد [5]. PoA یک نسخه اصلاح شده از PoS با هویت به عنوان تنها "سهام" است [14]. ما قراردادهای هوشمند خود را در یک شبکه آزمایشی خصوصی با استفاده از اثبات صلاحیت آزمایش کردیم.

بلاک چین و قراردادهای هوشمند اتریوم

یک نمای گسترده از اتریوم ممکن است جهان را به سه بخش تقسیم کند: بلاک چین، ریشه‌های آزمایشی شبکه و ساختارهای داده آزمایشی [شکل. 1b]. بلاک چین وضعیت شبکه را در زمان‌های خاصی ثبت می‌کند، پس از اینکه تراکنش‌ها وضعیت را تغییر دادند. وضعیت شبکه در درختان مرکل پاتریشیا ذخیره می شود که هر کدام دارای هش بالایی هستند. بلوک‌ها در زنجیره این مقادیر هش بالا را ذخیره می‌کنند، اما همه داده‌ها را در شبکه بلاک چین ذخیره نمی‌کنند (بسیار بزرگ است). داده های حالت در یک لایه پایگاه داده با استفاده از leveldb [15، 16] ذخیره می شوند. داده‌های حساب کاربری و داده‌های قرارداد هوشمند (شامل کد و داده‌های واقعی درج‌شده از طریق کد) در این ساختارهای داده‌ای ذخیره می‌شوند که فقط توسط گره‌های «کامل» و «بایگانی» همگام‌سازی می‌شوند (گره‌هایی که به قدرت محاسباتی و محاسباتی بیشتری نیاز دارند. ذخیره سازی) [16]. این گره ها جزء جدایی ناپذیر سلامت شبکه هستند. با این حال، پروتکل اتریوم همچنین حاوی یک گزینه گره "سبک" است که در آن فقط هدرهای بلوک همگام سازی می شوند [9].

اتریوم می‌تواند طیف گسترده‌ای از تراکنش‌ها را از طریق قراردادهای هوشمند، برنامه‌های کامل تورینگ خوداجرا که در ماشین مجازی اتریوم (EVM) اجرا می‌شوند و در فضای ذخیره‌سازی خود حفظ می‌کنند، انجام دهد [8]. EVM یک معماری مبتنی بر پشته دارد و می‌تواند چیزها را روی پشته (مانند عملیات بایت کد)، در حافظه (مثلاً متغیرهای موقت درون توابع)، یا در ذخیره‌سازی (مثلاً متغیرهای دائمی که ورودی‌های پایگاه داده را نگه می‌دارند) ذخیره کند. هر قرارداد هوشمند فقط می تواند در فضای ذخیره سازی خود بخواند و بنویسد. به منظور منصرف کردن توسعه دهندگان از نوشتن قراردادهای هوشمند ناکارآمد یا سخت، هزینه «گاز» مربوط به هر دستور ذخیره سازی و بازیابی است. همانطور که کاربران بلاک چین یک آدرس دارند، وضعیت قرارداد هوشمند نیز در یک آدرس منحصر به فرد خاص در وضعیت جهانی شبکه اتریوم قرار دارد که کاربران می توانند با آن تماس بگیرند. اگر کاربر گاز کافی نداشته باشد، تماس قرارداد و تراکنش مربوطه انجام نمی شود. قراردادهای هوشمند فرصتی را برای توسعه برنامه‌های کاربردی با عملکرد پیچیده در شبکه بلاک چین فراهم می‌کنند. ما از انعطاف‌پذیری برنامه‌نویسی قرارداد هوشمند برای ایجاد یک راه‌حل چالشی و راه‌حل جایگزین fastQuery استفاده کردیم که داده‌های فارماکوژنومیک را به روشی سفارشی در ذخیره‌سازی قرارداد برای به حداکثر رساندن کارایی ذخیره‌سازی و پرس‌وجو وارد می‌کند.

تنظیمات شبکه

ما راه‌حل‌های خود را در Truffle v5. 1. 18، یک ابزار خط فرمان برای اتریوم، توسعه داده و آزمایش کردیم، که یک محیط تست جاوا اسکریپت داخلی را برای ما فراهم کرد. در این شبکه، ما درج و پرس و جو را با حداکثر 10000 ورودی در پایگاه داده آزمایش کردیم. راه اندازی ما یک "شبکه توسعه" را تشکیل می داد که از شبکه عمومی اتریوم جدا بود. این پیکربندی خصوصی به ما این امکان را می‌دهد که قراردادهای خود را به طور گسترده توسعه و آزمایش کنیم، بدون اینکه مجبور باشیم هر بار قرارداد جدیدی را مستقر کنیم. در حالی که پیکربندی شبکه می تواند به شدت بر عملکرد در یک طرح اثبات کار تأثیر بگذارد، در طرح اثبات صلاحیت حداقل تأثیرات را دارد. شفر و همکاراننشان می دهد که افزایش تعداد گره ها در شبکه اتریوم خصوصی و اثبات اقتدار تأثیر قابل توجهی بر عملکرد ندارد [17].

مقداردهی اولیه زنجیره

راه‌اندازی زنجیره در Truffle خودکار است و فقط نیاز به تنظیم پارامترهای اساسی مانند محدودیت گاز و نام شبکه در یک فایل پیکربندی دارد. ما از مقادیر حد و قیمت گاز پیش فرض برای شبکه توسعه استفاده کردیم (به ترتیب 4712388 و 100 gwei). با هم، محدودیت گاز و مقادیر قیمت، حداکثر مقدار اتری را تعیین می‌کنند که می‌توان برای هزینه‌های تراکنش خرج کرد (نمی‌توان بیش از قیمت گاز * حد گاز خرج کرد). در طرح اثبات کار، قیمت گاز نیز بر سرعت تراکنش تأثیر می‌گذارد، زیرا استخراج‌کنندگان معاملات را با قیمت گاز سودآورتر استخراج می‌کنند [18]. برای توضیح دقیق قیمت گاز و پارامترهای حد گاز به [8] مراجعه کنید.

راه حل چالش: قرارداد هوشمند مبتنی بر شاخص و نقشه برداری چندگانه

راه حل چالشی ما از چهار نگاشت ذخیره سازی استفاده می کند که توسط یک شناسه عدد صحیح منحصر به فرد اختصاص داده شده به هر مشاهده درج شده در پایگاه داده به یکدیگر مرتبط شده اند [شکل. 1c]. نگاشت ها شبیه جداول هش هستند و امکان جستجوی کارآمد کلید-مقدار را فراهم می کنند. در اولین نگاشت از چهار نگاشت، که ما آن را پایگاه داده می نامیم، داده های فارماکوژنومیک را ذخیره می کنیم و به هر ورودی یک شناسه منحصر به فرد اختصاص می دهیم تا به عنوان کلید نگاشت عمل کند. ما هر مشاهده را در ساختار خاص خود ذخیره می کنیم، یک نوع داده ترکیبی که می تواند چندین فیلد را در خود جای دهد. در سه نگاشت دیگر، ما از نام ژن، شماره انواع و نام داروها به عنوان کلیدهای آرایه ای از شناسه های مربوطه استفاده می کنیم. بنابراین، با توجه به یک کلید نام ژن، می‌توان فهرستی از شناسه‌هایی را که می‌توانند به نقشه‌برداری پایگاه داده کلید بزنند، بازیابی کرد و مشاهداتی را که با آن نام ژن خاص مطابقت دارد، برگرداند. ما این پیاده‌سازی را به منظور کاهش تعداد حلقه‌های مورد نیاز برای بررسی داده‌ها در پایگاه داده و برگرداندن منطبق‌ها و در نتیجه دستیابی به پرس و جوی کارآمد زمان/حافظه انتخاب کردیم.

راه حل چالش: درج

داده ها را می توان از طریق دستورات یک خط در یک کنسول JavaScript یا از یک اسکریپت خارجی در یک قرارداد هوشمند وارد کرد. ما یک تابع درج در قرارداد نوشتیم تا یک مشاهده واحد را برای یک ترکیب نام شماره ژن نامگذاری نام خانوادگی درج نامگذاری کنید. در مورد ما ، مشاهده شامل نام ژن ، شماره نوع ، نام دارو ، نتیجه (بهبود یافته ، بدون تغییر یا بدتر شدن) ، رابطه مشکوک ژن (درست/نادرست) و عوارض جانبی جدی (درست/نادرست) است. پس از گذراندن مشاهده ، عملکرد مراحل زیر را اجرا می کند ، (1) هر زمینه از مشاهده را به نوع داده مورد نظر برای ذخیره سازی تبدیل می کند (به عنوان مثال ، ذخیره رشته ها به عنوان انواع بایت 32 در ذخیره سازی کارآمدتر است).(2) اگر نام ژن ، نوع ، ترکیب مواد مخدر از قبل در پایگاه داده وجود ندارد ، آن را به آرایه ای اضافه کنید که فقط نام ژن منحصر به فرد ، نوع و ترکیب نام دارو را داشته باشد..(4) فشار دادن به پایگاه داده نقشه برداری از ساختار با جفت ارزش کلیدی: Counter- [ساختار نگه داشتن مشاهده] ؛(5) متغیر پیشخوان افزایش توسط یک (به الگوریتم 1 مراجعه کنید).

ما نام ژن ، شماره نوع و قسمت های نتیجه را به عنوان متغیرهای بایت 32 ذخیره می کنیم ، یک آرایه بایت با اندازه ثابت که از گاز کمتری در اتریوم نسبت به رشته ها استفاده می کند و با استحکام سازگار است (به عنوان مثال ، بررسی ساده تر استطول متغیر بایت از متغیر رشته با استفاده از استحکام). ما نام دارو را به عنوان یک رشته ذخیره می کنیم زیرا بسیاری از نام های دارویی طولانی هستند و می توانند از حد 32 کاراکتر نوع داده بایت 32 فراتر رود. Booleans از نظر استحکام ساده است و آدرس ها انواع مختلفی برای ذخیره راحت کاربر یا آدرس های قرارداد در blockchain هستند.

راه حل چالش: الگوریتم پرس و جو

راه حل چالش ما می تواند هر دو نمایش داده های سه میدان را انجام دهد ، جایی که زمینه ها نام ژن ، شماره نوع ، نام دارویی و نمایش داده های کارت وحشی هستند. می توان با هر ترکیبی از این سه زمینه پرس و جو کرد ، یا به سادگی Gene = "*" ، Variant = "*" ، Drug = "*" را مشخص کرد ، که باید کل محتوای پایگاه داده را برگرداند. برای پرس و جو ، ابتدا بررسی می کنیم که چند زمینه پرس و جو شده است ، و برای مواردی که وجود دارد ، از فیلدهای پرس و جو استفاده می کنیم تا به نقشه برداری مناسب کلید بزنیم و مقدار مرتبط با آن کلید را برگردانیم - آرایه ای از شناسه های عدد صحیح مربوط به شناسه شناسهداده ها در نقشه برداری پایگاه داده. اگر همه زمینه ها "*" بودند ، ما از تمام شناسه هایی که در حال حاضر در حال استفاده هستند استفاده می کنیم تا داده ها را از نقشه برداری پایگاه داده برگردانیم. در غیر این صورت ، ما تعیین می کنیم که کدام یک از آرایه ها دارای حداقل طول هستند و از طریق آن حلقه می شوند (از آنجا که محتوای آن نتایج تقاطع مجموعه را محدود می کند). برای هر ورودی در این آرایه شناسه حداقل طول ، برای هر زمینه دیگری که جستجو شده بودیم از طریق آن آرایه شناسه حلقه می کنیم و بررسی می کنیم که آیا با شناسه در حلقه بیرونی مطابقت دارد یا خیر. در انتهای حلقه بیرونی ، اگر تعداد مسابقات برابر با تعداد فیلدهای جستجو شده باشد ، از این عدد صحیح استفاده می شود تا به نقشه برداری پایگاه داده و گرفتن مقدار ساختار ، که در آن زمان در یک آرایه حافظه ذخیره می شود ، استفاده شود. سپس ما از مجموعه ای از ترکیب های منحصر به فرد حلقه می کنیم و برای هر یک از استخر ساختار در نتایج جستجو که با آن ترکیب منحصر به فرد مطابقت دارد. این به ما اجازه می دهد تا داده ها را به روشی مفید تولید کنیم: برای یک نام ژن خاص ، شماره نوع و نام مواد مخدر ، چه تعداد مشاهدات وجود دارد ، چه تعداد و درصد موارد شاهد عوارض جانبی جدی است ، چه تعداد و درصد مشکوک به تعامل بینژن و دارو ، و چه تعداد و درصد در هنگام تجویز دارو ، نتیجه بهبود یافته ، بدتر یا بدون تغییر را مشاهده می کند (به الگوریتم 2 مراجعه کنید).

راه حل FastQuery: یک قرارداد هوشمند هوشمندانه ، مبتنی بر شاخص و چند نقشه برداری

به جای ذخیره هر مشاهده در ساختار خاص خود ، محلول متناوب ، FastQuery ما یک ساختار واحد را برای هر رابطه منحصر به فرد ژن-فرقه در حال ذخیره سازی ذخیره می کند. ما از چهار نقشه ذخیره سازی مرتبط با یکدیگر توسط یک شناسه اختصاص داده شده به هر مشاهده درج شده در پایگاه داده استفاده می کنیم ، و یک نقشه برداری پنجم اضافی برای پیوند شناسه ها به رابطه بی نظیر ژن-فریزر آنها. این طراحی متناوب تعداد ورودی های شناسایی شده در پایگاه داده را کاهش می دهد و از رشد پایگاه داده نامشخص جلوگیری می کند (تعداد نامحدودی از مشاهدات خام وجود دارد که می تواند در راه حل چالش ما وارد شود ، اما تعداد محدودی از روابط منحصر به فرد ژن-متغیر ژن وجود دارد که وجود دارد). ما این اجرای را به منظور کاهش طول حلقه های مورد نیاز برای بررسی داده های موجود در پایگاه داده و بازگشت مسابقات انتخاب کردیم و از این طریق زمان پرس و جو را بیشتر می کنیم.

راه حل FastQuery: درج

ما یک تابع جدید درج برای وارد کردن یک مشاهده واحد برای یک ترکیب نام شماره نام شماره ژن نامگذاری شده با نام ژن نوشتیم. پس از گذراندن مشاهده ، عملکرد مراحل زیر را اجرا می کند ، (1) هر زمینه از مشاهده را به نوع داده مورد نظر برای ذخیره سازی تبدیل می کند.(2) از ژن ورودی ، نوع و دارو به عنوان کلید ترکیبی در نقشه برداری پنجم استفاده کنید ، که شناسه را برای آن رابطه منحصر به فرد برمی گرداند.(3) از شناسه به عنوان کلید در نقشه برداری پایگاه داده استفاده کنید و بررسی کنید که آیا این رابطه قبلاً در پایگاه داده وجود دارد یا خیر.(4) اگر نه ، اطلاعات نام را از داده های ورودی پر کنید ، ژن ، نوع و نام مواد مخدر را به عنوان کلیدهای موجود در نگاشتهای مربوطه با شناسه به عنوان مقدار اضافه کنید و پیشخوان جهانی شناسه را توسط 1 افزایش دهید.(5) افزایش تعداد کل ، تعداد بهبود یافته ، تعداد رو به زوال ، تعداد مشکوک به رابطه و زمینه های شمارش عوارض جانبی ساختار رابطه در پایگاه داده بر اساس داده های درج شده. ما متغیرها را به عنوان همان نوع داده های مورد استفاده در راه حل چالش خود ذخیره می کنیم (به الگوریتم 3 مراجعه کنید).

راه حل FastQuery: الگوریتم پرس و جو

راه حل FastQuery ما می تواند هر دو نمایش داده های منحصر به فرد و Wildcard را مانند راه حل چالش انجام دهد. با این حال ، با FastQuery ، ما نیازی به تکرار از طریق مجموعه ای از ترکیبات منحصر به فرد ژن-Variant-Drug نداریم زیرا داده ها قبلاً در این روابط منحصر به فرد ذخیره شده اند. بنابراین ، ما به سادگی مسابقات را با استفاده از راه حل چالش بدست می آوریم ، داده های شمارش را به درصد تبدیل می کنیم و نتیجه جستجو را به دست می آوریم (به الگوریتم 4 و پرونده اضافی 1 مراجعه کنید).

نتایج

ما دو راه حل اثبات مفهوم برای ذخیره مشاهدات داده های فارماکوژنومیک ارائه می دهیم: راه حل چالش ما ، که ما در پایگاه داده های حداکثر 1000 مدخل و یک راه حل FastQuery متناوب با عملکرد بهبود یافته آزمایش کردیم ، که در پایگاه داده های حداکثر 10،000 مدخل آزمایش کردیم. هر دو راه حل برای دقت ، زمان ، مکان و راندمان گاز و مقیاس پذیری آن اندازه گیری شد [شکل ها. 2 و 3]

نتایج درج. زمان ، حافظه و استفاده از دیسک درج داده ها در دو راه حل قرارداد هوشمند ما. بار با استفاده از شبکه توسعه در ترافل اندازه گیری شد. هر دو راه حل چالش و FastQuery عملکرد درج قابل مقایسه را نشان دادند

نتایج پرس و جو. زمان ، حافظه و استفاده از گاز از داده های پرس و جو از دو راه حل قرارداد هوشمند ما. مقایسه عملکرد پرس و جو برای صفر ، یک و دو و نمایش داده شد. بار با استفاده از شبکه توسعه در ترافل اندازه گیری شد. FastQuy زمان و مقیاس پذیری قابل توجهی را برای همه نمایش داده شد

دقت

محیط Truffle امکان آزمایش از اسکریپت های JavaScript سفارشی را فراهم می کند. با استفاده از ادعاهای موجود در JavaScript ، ما بررسی کردیم که نتایج پرس و جو با زمینه های پرس و جو برای 100 نمایش داده شده تصادفی با صفر ، یک و دو "و" s "مطابقت دارد. راه حل های چالش و FastQuery.

راندمان زمان و فضا و مقیاس پذیری

درج

ما زمان ، حافظه و استفاده از دیسک مورد نیاز برای وارد کردن مقادیر فزاینده داده ها را در ذخیره قرارداد اندازه گیری کردیم ، جایی که هر درج یک مشاهده تجربی واحد از تعامل ژن-وارانت-دارو (به عنوان مثال ، GENE = "CYP3A5" ، Variant = 52، دارو = pegloticase ، نتیجه = بدون تغییر ، مشکوک به ژن-دارو = صحیح ، اثر جدی و جدی = درست) [شکل. 2]ما زمان درج را هنگام قرار دادن 200 ورودی به طور همزمان اندازه گیری کردیم (با مکث 1 ثانیه بین دسته ها ، که از زمان گزارش شده تفریق می شود). ما دریافتیم که راه حل چالش ما برای قرار دادن 1000 مشاهده ، با پیچیدگی زمان خطی ، تقریباً 400 میلی ثانیه طول می کشد. ما دریافتیم که نیاز حافظه برای درج 1000 مدخل 500 مگابایت در هر درج است. ما دریافتیم که استفاده از فضای دیسک به صورت خطی با ورودی های پایگاه داده افزایش می یابد و تقریباً 0. 92 مگابایت برای ذخیره 1000 ورودی لازم است.

راه حل FastQuery برای درج 1000 مشاهده ، با پیچیدگی زمان خطی ، تقریباً 152 میلی ثانیه طول می کشد [شکل. 2]نیاز حافظه برای وارد کردن 1000 ورودی در زنجیره حدود 500 مگابایت در هر درج است. استفاده از فضای دیسک به صورت خطی با ورودی های پایگاه داده افزایش می یابد ، و تقریباً 1. 6 مگابایت برای ذخیره 1000 ورودی لازم است. در حالی که راه حل چالش فقط می تواند برای کمتر از 2،000 ورودی درج شده ، نمایش داده شود ، ما توانستیم عملکرد راه حل FastQuery را برای پایگاه داده ها تا 10،000 ورودی درج در اندازه آزمایش کنیم.

پرس و جو

ما عملکرد الگوریتم پرس و جو خود را با آزمایش زمان ، گاز و حافظه مورد نیاز برای انجام یک پرس و جو سه میدان در یک پایگاه داده با تعداد فزاینده ای از ورودی ها برای 100 نمایش داده تصادفی اندازه گیری کردیم [شکل. 3]ما دریافتیم که راه حل چالش ما به طور متوسط تقریباً 300 میلی ثانیه طول می کشد تا یک پرس و جو از یک بانک اطلاعاتی از 1000 مدخل با پیچیدگی زمان خطی تخمین زده شود. ما همچنین نیاز حافظه را برای یک پرس و جو از یک پایگاه داده از 100 ورودی اندازه گیری کردیم و دریافتیم که تقریباً 0. 003 مگابایت در هر پرس و جو و خطی با افزایش ورودی های پایگاه داده است. با این حال ، راه حل چالش قادر به انجام نمایش داده شد در پیکربندی شبکه ما ، در پایگاه داده های بزرگتر از 2،000 مدخل. و ما به دلیل عدم موفقیت عملکرد اندازه گیری گاز ترافل ، نتوانستیم از گاز یا حافظه برای پرس و جو در پایگاه داده های بزرگتر از 500 مدخل استفاده کنیم.

الگوریتم FastQuery ما زمان پرس و جو را بهبود بخشید [شکل. 3]ما دریافتیم که تکمیل یک پرس و جو از یک پایگاه داده از 1000 مدخل و زمان خطی با افزایش تعداد ورودی های پایگاه داده ، تقریباً 170 میلی ثانیه طول می کشد. برای نیاز به حافظه پرس و جو ، تقریباً 0. 005 مگابایت در هر پرس و جو از یک پایگاه داده از 1000 مدخل نشان داد و با افزایش ورودی های پایگاه داده به صورت خطی افزایش یافت. نکته مهم ، FastQuery مقیاس پذیری بهبود یافته را نشان داد. ما توانستیم عملکرد FastQuery را برای بانکهای اطلاعاتی تا 10،000 مدخل اندازه گیری کنیم. ما دریافتیم که تکمیل یک پرس و جو از یک بانک اطلاعاتی از 10،000 مدخل و 0. 01 مگابایت تقریباً 790 میلی ثانیه طول می کشد.

تأثیر متفاوت "و" در پرس و جو

ما بررسی کردیم که آیا زمان و کارآیی حافظه دو راه حل ما با تعداد "و" S در یک پرس و جو متفاوت است [شکل. 3]ما بررسی کردیم که آیا برای یک بانک اطلاعاتی از 1000 مدخل ، تغییر تعداد زمینه های پرس و جو بر زمان و حافظه تأثیر می گذارد. ما دریافتیم که برای یک و دو نمایش داده شده در راه حل چالش ، به طور متوسط حدود 250 میلی ثانیه طول می کشد تا از یک پایگاه داده 1000 وارد سؤال کنیم ، در حالی که یک پرس و جو 0 و به طور متوسط تقریباً 585 میلی ثانیه طول می کشد تا همین کار را انجام دهدبشرما بدون در نظر گرفتن تعداد ANDS در پرس و جو ، استفاده از حافظه را در هر پرس و جو قابل مقایسه دانستیم.

برای راه حل FastQuery ، ما دریافتیم که برای یک و دو و دو نمایشگاه به طور متوسط تقریباً 165 میلی ثانیه برای پرس و جو از یک پایگاه داده 1000 وارد می شود ، در حالی که یک پرس و جو 0 و به طور متوسط تقریباً 570 میلی ثانیه طول می کشد تا همین کار را انجام دهد [شکل. 3]حافظه تقریباً 0. 005 مگابایت در هر پرس و جو برای یک پرس و جو ، 0. 006MB برای یک پرس و جو 1 و 0. 01 مگابایت برای یک پرس و جو در یک پایگاه داده از 1000 ورودی بود. یک و دو و دو نمایشگاه به طور متوسط تقریباً 750 میلی ثانیه برای پرس و جو از یک بانک اطلاعاتی 10،000 وارد می کنند ، در حالی که یک پرس و جو 0 و به طور متوسط تقریباً 2. 5 ثانیه طول می کشد تا همین کار را انجام دهد. حافظه تقریباً 0. 011 مگابایت در هر پرس و جو برای یک پرس و جو 2 و ، 0. 016MB برای یک پرس و جو 1 و 0. 028 مگابایت برای یک پرس و جو در یک پایگاه داده از 10،000 مدخل بود.

بحث

یکپارچگی بالا ، نگهداری داده های امن یک نگرانی عمده در تحقیقات زیست پزشکی است. در مورد فارماکوژنومیک ، داده های جمع آوری شده از آزمایشات بالینی به طور مستقیم بر تصمیمات درمانی پزشکی تأثیر می گذارد. یکپارچگی و امنیت داده ها بسیار مهم است ، زیرا ضرر یا فساد منجر به مراقبت های نادرست پزشکی می شود. مسابقه تجزیه و تحلیل ژنوم امن IDASH 2019 با استفاده از قراردادهای هوشمند در یک blockchain خصوصی Ethereum پیشنهاد شده است [19]. چنین راه حل هایی می تواند داده ها را در برابر از دست دادن در یک نقطه از سناریوی شکست و از فساد تصادفی یا عمدی محافظت کند. همچنین دارای پیامدهای گسترده تری است ، که نشان دهنده پتانسیل استفاده از فناوری blockchain برای حل مشکلات دنیای واقعی فراتر از cryptocurrency است.

در این مطالعه ، ما دو راه حل اثبات مفهوم برای ذخیره داده های فارماکوژنومیک با استفاده از پلت فرم blockchain Ethereum ارائه دادیم. هر دو راه حل نیاز به امنیت و دسترسی در به اشتراک گذاری این داده ها را برطرف می کنند ، بلکه نیاز عملی برای بهره وری زمان و حافظه برای استفاده در دنیای واقعی است. ما نشان دادیم که فناوری blockchain نه تنها می تواند امنیت و تغییر ناپذیری را ارائه دهد ، بلکه کارآیی و عملی را نیز ارائه می دهد. اگرچه ما به عنوان قراردادهای هوشمند Ethereum توانستیم دو راه حل کارآمد را توسعه دهیم ، اما توسعه در اتریوم بسیار آسان نیست. راه اندازی یک blockchain خصوصی در Ethereum به دانش تخصصی در این سکو نیاز دارد و استقرار قرارداد یک فرایند پیچیده است. این فرآیند را می توان به یک اسکریپت خارجی متراکم کرد ، که باعث می شود نیاز به تخصص برای استفاده از سکو کاهش یابد. با این وجود هنوز هم در نرم افزارهای اتریوم مانند Web3. JS ، API JavaScript برای Ethereum ، اشکالات مربوط به اشکالات وجود دارد. ما توانستیم بر این مسائل نرم افزاری غلبه کنیم ، اما قبل از شروع محققان از استفاده از آن برای یک پایگاه داده مشترک ، نیاز به ثبات بیشتر در این پلتفرم را تأیید کردیم.

نتیجه

به طور خلاصه ، ما یک راه حل چالش برانگیز برای ذخیره و جستجوی داده های فارماکوژنومیک در مورد blockchain Ethereum در یک قرارداد هوشمند و یک راه حل FastQuery متناوب با زمان و مقیاس پذیری قابل توجهی بهبود یافته ارائه دادیم. راه حل چالش ما از چندین نگاشت مرتبط با شناسه های عدد صحیح منحصر به فرد استفاده شده است. این طرح سودمند بود ، زیرا اجازه می داد با دسترسی مستقیم به نقشه برداری (در اصل جداول هش) ، پرس و جو را به جای تکرار در کل بانک اطلاعاتی ، پرس و جو با دسترسی مستقیم به نقشه برداری ها (اساساً جداول هش). راه حل FastQuery ما ذخیره داده های جمع شده را معرفی کرد ، که با از بین بردن نیاز به بررسی ترکیبات منحصر به فرد ژن-فر-دارو در پایگاه داده در هنگام پرس و جو ، زمان پرس و جو را کاهش می دهد. هر دو راه حل با زمان مقیاس پذیر و نیازهای حافظه تا 1000 نمایش داده می شوند. با این حال ، اگرچه راه حل چالش ما با موفقیت داده ها را ذخیره کرد ، اما برای انجام نمایش داده شد در یک زنجیره با بیش از 1000 مدخل ، به مقدار زیادی گاز نیاز داشت. راه حل FastQuery ما تا 10،000 مدخل با زمان مقیاس پذیر ، حافظه و گاز موفق بود. الگوریتم های ما باید با محدودیت های استحکام در ذهن طراحی شوند ، مانند تعداد متغیرهای محلی مجاز در یک عملکرد ، حد "گاز" و سایر خصوصیات برای توسعه اتریوم. راه حل های ما پتانسیل فناوری blockchain را در جامعه تحقیقات پزشکی نشان می دهد ، اما می تواند برای انواع دیگر مشکلات فروشگاه و پرس و جو استفاده شود.

منابع

Erlich Y ، Narayanan A. مسیرهای نقض و محافظت از حریم خصوصی ژنتیکی. Nat Rev Genet. 2014 ؛15: 409–21.

Nouriel Roubini می گوید: Kharpal A. Blockchain "یکی از بیشترین فن آوری های تا کنون" است. 2018. https://www.cnbc.com/2018/03/06/blockchain-nouriel-roubini-one-of-the-overhyped-technologies-ever.html. دسترسی به 28 مه 2020.

Kuo T ، Kim H ، Ohno-Machado L. Blockchain فن آوری های لجر را برای برنامه های مراقبت های بهداشتی و درمانی توزیع کرد. جمیا2017 ؛24 (6): 1211–20.

Nakamoto S. Bitcoin: یک سیستم نقدی الکترونیکی همتا به همتا. 2008. bitcoin.org/bitcoin. pdf. دسترسی به 28 مه 2020.

Browne R. IBM شرکای Nestle ، Unilever و سایر غول های غذایی برای ردیابی آلودگی مواد غذایی با blockchain. 2017. https://www.cnbc.com/2017/08/22/ibm-nestle-unilever-walmart-lockchain-food-contination.html. دسترسی به 28 مه 2020.

Wood G. Ethereum: یک نسخه بیزانس معامله عمومی غیر متمرکز بر معامله غیر متمرکز. 2019. https://ethereum. github.io/yellowpaper/paper. pdf. دسترسی به 28 مه 2020.

یک قرارداد هوشمند نسل بعدی و بستر برنامه غیر متمرکز. 2019. https://github.com/ethereum/wiki/wiki/white-paper. دسترسی به 28 مه 2020.

TSO R ، Liu Z ، Hsiao J. سیستم های رأی گیری الکترونیکی و پیشنهادات الکترونیکی را بر اساس قرارداد هوشمند توزیع کرد. الکترونیک2019 ؛8: 422. https://doi.org/10. 3390.

King S ، Nadal S. Ppcoin: ارز رمزنگاری همتا به همتا با اثبات سهام. 2012. https://decred.org/research/king2012. pdf. دسترسی به 28 مه 2020.

عملکرد و مقیاس پذیری blockchains خصوصی Ethereum. 2019. https://publik. tuwien. ac. at/files/publik_280601. pdf. دسترسی به 28 مه 2020.

کارگاه حریم خصوصی و امنیت IDASH 2019 - رقابت تجزیه و تحلیل ژنوم امن. 2019. http://www.humangenomeprivacy.org/2019/competition-tasks.html. دسترسی به 28 مه 2020.

سپاسگزاریها

ما از سازمان دهندگان IDASH بخاطر ارائه راه برای توسعه برنامه های امن برای تجزیه و تحلیل ژنوم تشکر می کنیم.

منابع مالی

این کار توسط موسسه ملی بهداشت ایالات متحده U01 EB023686 کمک مالی و توسط صندوق های استادی آل ویلیامز پشتیبانی می شود. هزینه های انتشار توسط مؤسسات ملی بهداشت U01 EB023686 ایالات متحده تأمین شد.

اطلاعات نویسنده

Gamze G "Rsoy و Charlotte M. Brannon به طور مساوی در این کار نقش داشتند.

نویسندگان و وابستگی ها

برنامه در زیست شناسی محاسباتی و بیوانفورماتیک ، دانشگاه ییل ، خیابان ویتنی ، نیو هاون ، 06520 ، CT ، ایالات متحده

Gamze Gürsoy & Mark Gerstein

گروه بیوفیزیک مولکولی و بیوشیمی ، دانشگاه ییل ، خیابان ویتنی ، نیو هاون ، 06520 ، CT ، ایالات متحده

Charlotte M. Brannon & Mark Gerstein

گروه علوم کامپیوتر ، دانشگاه ییل ، خیابان Prospect ، New Haven ، 06520 ، CT ، USA