Ние сме развълнувани да обявим интегрирането на fitchain с Ocean Protocol. Прочетете повече за технически подробности относно водопровода за интегриране чрез Споразумения за изпълнение на услуги (SEA). Тази публикация в блога е съавтор на Франческо Гадалета.

Как работи

fitchain е децентрализирана мрежа, която позволява на доставчиците на модели (напр. специалисти по данни) да обучават своите модели на данни, предоставени от собствениците на данни. Изчислението се извършва дистанционно от самия доставчик на данни или от делегиран участник — наричан доставчик на изчисления. Това е модел на изпълнение, който разчита на изолиране на данни, за разлика от чисто криптиране на данни, за да помогне защитите данните на място.

Традиционните канали за машинно обучение също разчитат на тестване и валидиране на моделите след обучение. Такава стъпка на валидиране обикновено се извършва от специалисти по данни, които „обещават“ да бъдат етични при тестване на своите модели с така наречените данни „извън извадката“ (OOS); данни, които са различни от набора от наблюдения, използвани за обучение. В интерес на истината, тестването на модел върху същия набор от данни за обучение ще увеличи точността му, правейки целия процес не само безполезен (защото моделите няма да обобщават невиждани наблюдения), но и технически измамен.

В мрежата fitchain допълнителни участници се уверяват, че това „нежелано“ поведение (или липса на опит) на специалистите по данни се открива и в крайна сметка спира, като по този начин възпрепятства търгуемостта на обучения модел в рамките на пазара. Примери за този тип актьори са Клюкари и Проверяващи.

За да се опрости обяснението, по-долу са всички участници, участващи в сложната задача за обучение на модел за машинно обучение по децентрализиран и ненадежден начин.

В последната колона на таблица 1 е посочено дали даден участник залага в системата, преди да продължи. От някои участници се изисква да залагат веднъж на наличен слот. Един слот представлява колко изчислителен капацитет би могъл да осигури даден актьор за конкретната задача. Например, CP с мощен GPU може да обучава няколко модела наведнъж; по подобен начин верификатор може да провери множество модели; и Gossiper може да излъчва и репликира регистрационни файлове за множество модели, при условие че има достатъчна мрежова честотна лента и място за съхранение.
Най-общо казано,

  • Клюкарите залагат, за да участват в изборите (график за избори като „Round-Robin“, все още предразположен към 51% атака), за да клюкарстват в специален канал, който се създава всеки път, когато се появи нов модел обучени.
  • Верификаторите допринасят за сигурна „схема за ангажиране и разкриване“, за да избегнат предната атака и следователно трябва да залагат, преди да бъдат избрани за игра за проверка.
  • Доставчикът на компютърни услуги (CP) трябва да заложи, за да генерира транзакции по време на обучението на модела. Този залог помага за предотвратяване на неограничено генериране на фалшиви транзакции, които могат да доведат до DoS атаки. Всеки CP отговаря за залагането въз основа на броя на наличните слотове.
  • Доставчикът на данни (DP) залага, докато обучението на модела завърши.
  • Потребителите всъщност не залагат, но заключват плащания, които ще бъдат освободени, след като всички условия бъдат доказани от мрежата.

Игра на клюкари

Когато нов модел стартира изчислителната задача, се създава нов клюкарски канал от договорите на Fitchain Ethereum. В такава мрежа редица клюкари ще излъчват регистрационните файлове на транзакциите, произведени от CP, които са адресирани до MP чрез „държавен канал“. Без такава мрежа регистърът на транзакциите би станал труден за оспорване, тъй като ще има само двама активно включени участници, а именно CP и MP. Освен това, ако един от двамата участници или прекъсне връзката, или се държи неправилно (например чрез умишлено скриване на транзакции), ще стане невъзможно възстановяването на такива транзакции, без да започне отново процеса на обучение. Това би било непосилно в някои случаи (напр. обучение на модели срещу изключително големи масиви от данни) и може да бъде много скъпо и времеемко за повторно инстанциране.

За разлика от тях, клюкарите са отговорни за получаването на регистрационни файлове, подписването им като потвърждение и излъчването им на съседите им според „протокол, подобен на kademlia“, дефиниран от fitchain.

Краят на обучението се маркира със специална транзакция, наречена End-of-Training (EoT). Клюкар, който получава EoT транзакцията и е съхранил всички транзакции от началото на обучението, може да предостави доказателство на мрежата. Доказателствата се представят от определен брой клюкари към интелигентния договор, който ще зададе model.isTrained = true веднага щом се постигне консенсус. Ние наричаме такова доказателство доказателство за обучение (PoT).

Игра за верификатори

Целта на PoT е само да докаже, че даден модел е бил обучен, при условие че CP не е фалшифицирал такива транзакции, без действително да обучи модел. Както споменахме, обучените модели все още изискват процес на проверка с тестови данни, използващи данни, които не са били използвани от CP по време на обучението. Изключително трудно е да се попречи на CP да инжектират данни с ниско качество или фалшиви данни по време на процеса на обучение, поради факта, че обучението се провежда частно и изолирано. Тази задача има точно същата трудност като в традиционния случай на наемане на учен по данни, който фалшифицира резултати, с единствената разлика, че такъв учен по данни ще бъде уволнен или преследван, ако такова поведение бъде открито.

За да се бори с този вид измамна дейност, fitchain прави живота на злонамерените CP труден чрез:

  1. Изискване на копие от дървото Merkle на данните, заявени като набор от данни за обучение, когато данните бъдат публикувани;
  2. Изискване на корен на Merkle за всяка партида данни, използвана по време на обучението на модел
    (CP автоматично ще изпрати такава информация само чрез използване на истински fitchain-pod);
  3. Внедряване на механизъм за разкриване на данни за проверка на данните за обучение по всяко време след като моделът е бил обучен.

Верификаторите са актьори, които изпълняват играта за проверка на модела, като тестват модели с външни, специфични за домейн набори от данни, евентуално курирани от експерти по домейни (напр. куратори на океански данни).

Задачата на vпроверяващите е да извличат обучени модели и подбрани набори от тестови данни и след това да извършват изчисления извън веригата, за да оценят точността/грешката на такива модели. Очевидно, за да извършат проверка, проверяващите използват ресурси като CPU/GPU и честотна лента на мрежата. Поради тази причина те получават възнаграждение от мрежата, при условие че е постигнат консенсус.

Само след завършване на играта за проверка моделът ще бъде маркиран като проверен (model.isVerified = true) и готов за изпращане до потребителя.

споразумение за изпълнение на услугата fitchain

Както бе споменато в предишните публикации в блога „представяне на споразуменията за услуги на Ocean“ и „Споразумението за изпълнение на услуги“ (SEA) на Ocean, споразумението за услуги е предназначено да бъде дефиниция на очакванията и задълженията на всеки участник с цел намаляване на бъдещи конфликти. Това определение уточнява комуникационните механизми, разрешаването на спорове и общите стратегии или действия, които всеки рационален участник е длъжен да спазва.

fitchain SEA шаблон

fitchain SEA е базиран на океана SEA шаблон, който се определя от набор от условия на обслужване с модел на зависимост, който ги свързва. Всяко условие е свързано с едно или повече доказателства във веригата. Фигурата по-долу показва примерен шаблон за fitchain SEA, включително минималните жизнеспособни условия за използване на fitchain услуги в Ocean.

Договорът за условията за изчисление отговаря за изпълнението на едно условие, както и договорът за контрол на достъпа (извършва се чрез тайно хранилище). От друга страна, договорът за условия на fitchain отговаря за изпълнението на три условия. Всички тези договори са предварително дефинирани и внедрени в мрежата на Ocean.

Този примерен шаблон не включва разрешаване на спорове (на ниво проверка) и сигурни условия за изчисление; все пак, имайте предвид, че модулният дизайн на Ocean SEA може да поддържа бъдещи надстройки.

Жизненият цикъл на SEA се определя от три фази:

Фаза на дефиниране на SEA

Ocean SEA предоставя основните примитиви за дефиниране на условията, както и модела на зависимост, на SEA шаблон. Тези примитиви включват връзката между условието и неговото изпълнение и дефиницията на модела на зависимостта. Връзката се интерпретира като ключ (или идентификатор) на условие, койтое дефиниран по следния начин:

  • Hash(smartContractAddress, functionSignature(selector), dependencyConditionsKeys(ifExist)).

Това означава, че ключът на условието е твърдо кодиран с пръстов отпечатък на специфична функция („селектор на функция за солидност“) в интелигентен договор. Това е единствената оторизирана функция, която отговаря за изпълнението на условието. Следователно интелигентният договор може да се справи с едно или повече условия, като дефинира множество функции за изпълнение.

Фигура 2 показва как е конструиран модел на зависимост за произволен шаблон на Ocean SEA:

Моделът на зависимост е вграден или кодиран в шаблона по отношение на dependency bits array. Всяко условие в този масив е представено от 2-bits. Първият бит се отнася до dependency condition index, а вторият бит се отнася до timeout flag. Например, ако имаме 5 условия, имаме нужда от 2 x 5 бита, за да представим зависимостта на условието в масив от пет елемента. Така че, използвайки побитови операции, договорите на Ocean SEA могат лесно да проверят представянето на зависимостта и да решат дали текущата функция за изпълнение отговаря на условията за изпълнение на текущото условие или не.

Този подход има две предимства:

  • Той запазва хранилището във веригата чрез компресиране на флаговете за зависимост в няколко бита; и,
  • Това позволява на Ocean SEA да използва повече функции в модела на зависимост за следващите версии.

Шаблонът може да се дефинира веднъж и да се използва много пъти. По този начин новите доставчици на услуги имат възможност да разработят свои собствени шаблони чрез добавяне на нови условия или групиране на предварително дефинираните условия. Те обаче могат също така да използват директно предварително дефиниран шаблон, като присвоят идентификатора на шаблона на своите услуги.

Фаза на изпълнение на SEA

В тази фаза участниците подписват споразумението и го изпращат във веригата. След това договорът на Ocean SEA проверява подписите и уведомява участниците да започнат играта. По време на настройката доставчикът на услугата ще бъде помолен да изпрати входните стойности и стойностите за изчакване (също подписани стойности), които са необходими за изпълнение на условия, включително DID на актив/услуга, цена, потребителски адрес, доставчици, адреси на издатели и др. В този момент условията на шаблона се създават чрез генериране на нови екземпляри на условие = Hash(conditionKey, inputsValueHash), където хешът на входната стойност представлява всички свързани входове за условието във функцията за изпълнение. Следователно, ако злонамерен актьор се опита да измами, като подаде невалиден вход към функцията за изпълнение, функцията ще реконструира невалиден ИД на екземпляр на условие и интелигентният договор на Ocean SEA ще върне повикването със съобщение за грешка.

И къде се съхраняват входните стойности? Просто те са дефинирани в DID документа за услуга/актив. Този DID документ описва представянето извън веригата на SEA шаблона, условията и свързаните с тях входни стойности. Документът DID предоставя подробно описание за обслужване на активи с данни от доставчици на данни в Ocean.

Фаза на прекратяване на SEA

SEA шаблонът на Ocean трябва да бъде проектиран да прекратява. Това означава, че имаме два вида прекратяване: изпълнени и неизпълнени споразумения. Някои ключови функции са:

  • Като рационален доставчик на услуги ще бъдете стимулирани да имате по-висок ранг, като изпълнявате SEA колкото е възможно повече. Освен това имате право да напишете свои собствени условия (т.е. конкретна самоличност).
  • Като рационален потребител важно ли е да свършите работата си възможно най-скоро. Освен това, като консумирате услуги, вие подготвяте споразумения за услуги. Това означава, че качеството на услугата ще се повиши.

Налагане на fitchain SEA в Ocean

Фигура 3 обобщава начина, по който специалистите по данни използват услугата fitchain чрез Ocean чрез подписване на споразумение за услуга.

От страната на океана по същество имаме трима актьори:

  • Data-Scientist — действа като модел доставчик и потребител;
  • Доставчик на услуги на fitchain — действа като доставчик на данни и доставчик на изчисления;
  • Свидетели на океана — избрани актьори, които отговарят за свидетелството на доказателствата чрез препратка във fitchain.

Актьорите са задължени да следват стъпките по-долу (т.е. щастливия път):

  • Специалист по данни избира данни и изчислителни активи, както и SEA шаблон чрез пазар на fitchain (пазар, регистриран в Ocean).
  • Data-scientist подписва SEA шаблон със стойности, след което изпраща подписано съобщение до доставчика на услугата fitchain (SP).
  • fitchain SP приема заявката, като създава нов Ocean SEA във веригата.
  • Актьорите ще бъдат уведомени за установените условия, като слушат събитията от договора Ocean SEA.
  • Data-scientist заключва плащането в договора за възнаграждение, за да започне играта, след което изпраща алгоритъма до крайната точка на услугата SP.
  • В този момент и двете страни (специалистът по данни и SP) са задължени да си сътрудничат, за да изпълнят проверката за целостта на данните на изпратения алгоритъм. По този начин специалистът по данни ще изчисли хеша на изпратения алгоритъм, ще го подпише и ще изпрати подписания хеш (само подпис) към договора за изчислителни условия. Ако SP получи същия алгоритъм, той ще може да изпълни условието, като изпрати хеша на изпратения алгоритъм.
  • Сега работата е делегирана на fitchain SP, който от своя страна ще обучи модела в мрежата на fitchain, където клюкарите ще бъдат избрани да подадат PoT. По същия начин верификаторите представят доказателството за проверка. И накрая, SP ангажира PoT и референтните идентификатори за доказателство за проверка от страната на океана.
  • Океанските свидетели използват идентификатора на модела (service agreement Id on the Ocean side) и удостоверените идентификатори на доказателство, за да проверят PoT и доказателството за проверка от страна на fitchain. След това гласуват от страната на океана.
  • Ако и двете условия model.isTrained и model.isVerified са true, SP ще предостави на специалистите по данни достъп до резултатите чрез тайното хранилище на Ocean.
  • И накрая, функцията за възнаграждение се задейства от SP, където оценява състоянието на условията и освобождава плащането, ако всички условия са изпълнени.

fitchain SEA интеграция

Както е показано в таблица 2, по дизайн Ocean SEA се основава на „архитектура, управлявана от събития“, където всяко ново условие трябва да бъде свързано с манипулатор извън веригата (софтуерен модул). Манипулаторът основно се абонира за събитие(я) на условие във веригата и предприема съответните действия(я) във веригата или извън веригата. Тези модули са включени в мрежовия интерфейсен компонент на Ocean (Squid Python, JS, Java), което от своя страна улеснява взаимодействието с договорите на пазителя. Ключовите характеристики на такива модули са, че те са модулни, капсулирани и слабо свързани.

Като се има предвид това, са необходими допълнителни реализации, за да се завърши интеграцията. Ние обобщаваме това по-долу:

  • Прилагане на един договор („договор с условия на fitchain“), който изпълнява както PoT, така и доказателството за проверка чрез препратка, което се извършва от страна на протокола Ocean.
  • Същото важи и за модулите извън веригата, които обработват условните събития и налагат целостта на доказателствата от страна на fitchain.

Ключовият момент е, че споразуменията за услуги в Ocean обикновено се определят от заинтересованите страни или общността, които участват в играта. Следователно ролята на Ocean SEAs е да осигури средствата за описване и опериране/изпълнение на споразуменията и да даде властта на общността да развива свои собствени условия. Очакваме с нетърпение следващите Ocean sailors.

Благодаря на Don Gossen, Dimitri De Jonghe, Aitor Argomániz , Samer Sallam, Fang Gong, John Enevoldsen, Kwinten Crauwels, Sebastian Gerske

Полезни връзки

Надяваме се, че сте готови да се потопите — разгледайте Dev-Ocean, за да добиете представа върху какво сме работили, и задайте всичките си технически въпроси в нашата чат стая на Gitter.

Следвайте Ocean Protocol в Twitter, Telegram, LinkedIn, Reddit, GitHub & Бюлетин за актуализации и съобщения за проекти.