Wprowadzenie

Coraz częściej pojawiający się ostatnio buzzword to blockchain:

System, którego nie da się złamać. Sam zaś może zmienić oblicze wielu branż. Blockchain rewolucjonizuje sposób zawierania, rozliczania i zapisywania transakcji. […] Technologia ta…¹

Ostatnio raczej właśnie w takim tonie coraz częściej można spotkać się z hasłem blockchain. Tego typu nagłówki i treści wyszły z prasy branżowej IT i pojawiają się w prasie z obszaru finansów, ekonomii gospodarki, blogach menedżerskich. Lawinowy wzrost kursu bitcoin’a spowodował, że każde kojarzone z nim pojęcie natychmiast pojawia się w nagłówkach…

Blockchain

Cóż to takiego? Kwestię krypto-waluty, jaką jest bitcoin, pominę tu całkowicie, pominę także detale technologii wykorzystanych w implementacji kryptowaluty bitcoin, gdyż nie ma ona wpływu na przedmiot tego tekstu. Kluczowe pytanie brzmi: blockchain to technologia czy system oraz gdzie to się może przydać?

Najpierw kluczowe pojęcia:

technologia
1. ?metoda przeprowadzania procesu produkcyjnego lub przetwórczego?
2. ?dziedzina techniki zajmująca się opracowywaniem nowych metod produkcji wyrobów lub przetwarzania surowców?

procedura
1. ?określone reguły postępowania w jakiejś sprawie, zwykle o charakterze urzędowym lub prawnym?
2. ?w językach programowania: wydzielony fragment algorytmu?

algorytm mat. ?ściśle określony ciąg czynności, których wykonanie prowadzi do rozwiązania jakiegoś zadania?

scenariusz
1. ?tekst stanowiący podstawę filmu, przedstawienia lub audycji?
2. ?szczegółowo przygotowany program jakiejś imprezy lub jakiegoś spotkania?
3. ?zaplanowany lub przewidywany rozwój wydarzeń?

własność
1. ?to, co ktoś posiada?
2. ?prawo do rozporządzania rzeczą z wyłączeniem innych osób, w granicach określonych przez ustawy i zasady współżycia społecznego?

system ?układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość?

Na początek troszeczkę reguł dotyczących dotyczących prawa własności, gdyż wszelkie transakcje wymiany czegokolwiek, nie tylko w ekonomii,  można w zasadzie sprowadzić do pojęcia wymiany, przeniesienia własności środków stanowiących walutę, stanowiących zapłatę za przekazany towar lub usługę. W komunikacji elektronicznej sprowadza się to praktycznie do przeniesienia danych i wiarygodności tej transakcji.

Pojęcie “własności” to pojęcie z dziedziny prawa. Pojęcie posiadać coś (wziąć w posiadanie) oznacza odebranie innym podmiotom prawa do dysponowania tym czymś.  Tak więc powiedzieć, że się ma jakieś bitcoiny oznacza, że nikt, poza nami, nie ma prawa nimi dysponować (czym by nie były). Przekazanie komuś prawa własności (sprzedanie) czegoś, oznacza, że sprzedający traci prawo dysponowania przedmiotem transakcji a nabywca zyskuje je. To są prawa podmiotowe do przedmiotu,  tak zwane pojęcia pierwotne w prawie, pojęciem wtórnym jest tu przedmiot i wskazanie właściciela podmiotu mającego wyłączne prawo dysponowania: prawa przedmiotowe (do przedmiotu). Innymi słowy na co dzień nie mówimy, że nikt poza nami nie ma prawa dysponowania danym przedmiotem, mówimy że jesteśmy posiadaczem tego przedmiotu.² Kluczowy jest tu fakt, że przedmiot może mieć w danym momencie tylko jednego właściciela (także zbiorowego, wtedy ma on nazwę) lub nie mieć go wcale (nikomu nie ograniczono prawa władania przedmiotem). Procedura realizacji transakcji sprzedaży (przeniesienia praw własności) formalnie wygląda tak: (1) pozbawienie prawa własności osoby sprzedającego, (2) nadanie prawa własności osobie kupującego. Jak widać jest tu moment gdy nikt nie jest właścicielem przedmiotu. Musi tak być, bo nie jest logicznie możliwe jednoczesne władanie przedmiotem przez dwa podmioty.

Tyle logika :). Kluczem do dalszej części jest procedura realizacji transakcji sprzedaży. To – chwilowy brak właściciela – pokazuje, że potrzebna jest tu albo zaufana trzecia strona (np. bank pośrednik), albo uczciwość uczestników transakcji (jak np. my kupując coś w sklepie), albo procedura uniemożliwiająca nieuczciwe zachowanie uczestników transakcji.

Trzecia strona zaufania

Sama idea zabezpieczenia transakcji bez trzeciej strony zaufania (nie chcemy wśród siebie nikogo o tak uprzywilejowanej pozycji) jest wbrew pozorom prosta: transakcja przeprowadzana jest przy świadkach (sprzedaż odbywa się publicznie na oczach wielu) i zawarto umowę, że nikt nie przywłaszczy sobie przedmiotu w trakcie transakcji. To tworzy założenie, że nikt nie ma interesu w tym by jawnie oszukać. Wyzwaniem jest tu jednak odwzorowanie roli publiczności w sposób pozwalający, mimo wszystko, zachować w tajemnicy strony i przedmiot transakcji (co stanowi tu jednak łyżeczkę dziegciu w beczce miodu). Czyli sprzeczność? Troszkę tak…

Prosta wersja opisanego wyżej mechanizmu to rozproszenie śladu transakcji. Najprostszą metodą jest zasada: dokument opisujący transakcję – faktura – jest przechowywany w dwóch miejscach: u sprzedającego i u kupującego. Sfałszowanie tego dokumentu wymagało by zmowy obu stron (co jest mało prawdopodobne), bo w przypadku faktur ta zmowa jest trudna, z uwagi na sprzeczny interes obu stron: kupujący chce zaksięgować koszt zakupu co mu obniży podatek, sprzedający musi (niechętnie :)) zaksięgować przychód do opodatkowania. Nie istnieje tu kompromis więc pozostaje zachowane stanu (wartość transakcji) faktycznego, ta sama treść faktury w dwóch miejscach o sprzecznym interesie, pozwala uznać, że  identyczność treści stanowi potwierdzenie prawdziwości.

Wadą tego podejścia jest to, że kontrola wszystkich dokumentów jednego podmiotu jest czasochłonna bo wymaga kontaktu z wieloma podmiotami (drugimi stronami każdej transakcji). Nie ma problemu gdy transakcja jest bezpośrednia. Problem zaczyna się wtedy, gdy potrzebne jest zaufanie do kontrahenta odległego. Skoro procedura realizacji przeniesienia własności ma trzy stany (właściciel A, brak właściciela, właściciel B) to nie istnieje jednoczesność więc ustalenie co najpierw: przekazać produkt czy przekazać pieniądze, staje się grą analogiczną do dylematu więźnia (nieuczciwy wygrywa)³.

Tak więc mechanizm użycia dużej publiczności, dla pary podmiotów realizującej transakcję sprzedaży, daje dużą pewność, ale jest problem z kryptowalutami: strony transakcji i publiczność chcą pozostać anonimowi. Dlatego mechanizm został wzbogacony o kontakty z publicznością (obserwatorzy transakcji czyli Ci którzy ją uwiarygadniają) metodą kodowanych bloków danych z użyciem rozproszonej bazy danych. Pokazano to na poniższym diagramie⁴:

Cała idea bazuje na przyjęciu wersji, że najpierw pieniądze a potem towar (a nie odwrotnie), gdzie towarem (tu) są np. bitcoiny. Zmorą tego systemu jest jednak wymóg anonimowości, który zaowocował dodatkową złożonością z powodu potrzeby implementacji autoryzacji i przyjęcia relatywnie dużej, uwiarygodnienie przez publiczność, liczby podmiotów autoryzujących transakcje. Wikipedia podaje, że z tego powodu transakcje cechuje wysoki koszt energetyczny każdej z nich (podobno zużycie energii elektrycznej per transakcja odpowiada dziennemu zapotrzebowaniu przez typowe amerykańskie gospodarstwo domowe), stosunkowo długi czas zatwierdzania transakcji, niska wydajność.

Jednak pomijając detale, sama metoda oparta na zaufaniu budowanym poprzez dystrybucję ryzyka i odpowiedzialności ma wszelkie znamiona powodzenia jako metoda tworzenia zaufanej (wiarygodnej) komunikacji elektronicznej, bez potrzeby stosowania wyrafinowanych, kosztownych metod kodowania skazujących pomysł na konkretną technologię i algorytmy… Takie zabezpieczenie to system podmiotów biorących udział w transakcjach i ustalona kolejność kroków działania, który można zaimplementować jako procedurę a nie jako technologię.

Tak więc czy blockchain to technologia? Jeżeli mamy na myśli konkretne rozwiązanie zastosowane na rynku bitcoina, to są to konkretne technologie użyte do realizacji procedury sprzedaży. Jeżeli uznamy, że jest to proceduralne zabezpieczenie transakcji, to jest to procedura a nie technologia. Jeżeli piszemy o blochchain jako o metodzie autoryzowania transakcji elektronicznych to mamy na myśli procedurę a nie technologię. Ciekawe jest to, że o jakimkolwiek łamaniu zabezpieczeń można mówić wyłącznie wtedy, gdy elementem systemu będzie jakiekolwiek np. szyfrowanie czy podpisywanie. Jeżeli system będzie jawny i zostanie oparty wyłącznie na procedurach, znikają technologiczne zabezpieczenia i szyfry a więc nie ma czego łamać…

Podsumowanie

Tak więc wydaje się, że proceduralne metody gwarantowania transakcji jednak są lepsze od podpisów elektronicznych, bo łatwiejsze w implementacji i odporniejsze na nieuczciwość w sieci. Każdy typ transakcji zapewne będzie miał swoją procedurę, gdyż to ryzyko wyrządzenia szkody przez oszusta i wielkość tej szkody powinny decydować o kosztach zabezpieczenia a nie uznanie, że stosujemy z zasady metody najbezpieczniejsze czyli najkosztowniejsze. Tu po raz kolejny przytoczę przykład rocznych deklaracji podatkowych w Polsce: rezygnacja z e-podpisu spowodowała lawinowy wzrost  liczby deklaracji składanych drogą elektroniczną przy praktycznie zerowej liczbie nadużyć i bez kosztów posiadania kwalifikowanego podpisu elektronicznego⁵.

Czy Blockchain komplikuje proces, a czy wnosi jakąś wartość dodaną? Uważam, że w świecie biznesowym anonimowość to ostania oczekiwana rzecz, dlatego każda kodowana transmisja peer-to-peer (punkt punkt), taka jak np. SSL czy EDI, jest zupełnie wystarczająca i “wpychanie” tu Blockchain nie wnosi niczego poza komplikacją.

Wprowadzenie

Tematem numer jeden, niemalże w każdym moim projekcie, jest model biznesowy i tajemnica przedsiębiorstwa. Z perspektywy lat muszę powiedzieć, że to fobia wielu (jak nie większości) przedsiębiorców i nie tylko przedsiębiorców. Nie dlatego, że chcą coś chronić, ale dlatego co i jak chronią. Nie raz już pisałem, że firmy nie raz, najpierw podpisują z dostawcami rozwiązań i konsultantami umowy o poufności, a potem wyzbywają praw do swojego know-how na ich rzecz:

W branży inżynierii oprogramowania dość powszechna jest sytuacja, gdy programista jest także projektantem, innymi słowy programista ma pełnię praw autorskich do kodu jaki tworzy a jego klient żadnych mimo, że jest inwestorem!¹

Dzisiaj drugi problem czyli bezpieczeństwo informacji a nie raz i całej firmy.

Na początek coś z zakres teorii informacji:

Zasada Kerckhoffs’a to jedna z podstawowych reguł współczesnej kryptografii. Została sformułowana pod koniec XIX wieku przez holenderskiego kryptologa Augusta Kerckhoffs’a (ur. 19 stycznia 1835, zm. 9 sierpnia 1903). Zasada ta mówi, że system kryptograficzny powinien być bezpieczny nawet wtedy, gdy są znane wszystkie szczegóły jego działania oprócz sekretnego klucza. […]

1. System powinien być, jeśli nie teoretycznie, to w praktyce nie do złamania.
2. Projekt systemu nie powinien wymagać jego tajności, a ewentualne jego ujawnienie nie powinno przysparzać kłopotów korespondentom.
3. Klucz powinien być możliwy do zapamiętania bez notowania i łatwy do zmienienia.
4. Kryptogramy powinny być możliwe do przesłania drogą telegraficzną.
5. Aparatura i dokumenty powinny być możliwe do przeniesienia i obsłużenia przez jedną osobę.
6. System powinien być prosty ? nie wymagający znajomości wielu reguł ani nie obciążający zbytnio umysłu.

Właśnie druga z tych reguł nosi obecnie nazwę zasady Kerckhoffs’a.

[…]Ideę zasady Kerckhoffs’a wyraża również przypisywane Claude’owi Shannon’owi powiedzenie “Wróg zna system” (ang. The enemy knows the system), znane pod nazwą Maksymy Shannona (ang. Shannon’s maxim).²

Zasadę tę, jako kryterium, można łatwo poszerzyć, usuwając ostatnie słowo do postaci:

Projekt systemu nie powinien wymagać jego tajności, a ewentualne jego ujawnienie nie powinno przysparzać kłopotów.

Na rynku mamy dwa przeciwstawne w pewnym sensie (o tym dalej) pojęcia: patent oraz know-how, dodać należało by do tego zestawu pojęcie prawo autorskie osobiste i majątkowe.

O bezpieczeństwie biznesowym

Na początek klasycznie kluczowe definicje:

know-how: rozumiane jest jako pakiet nieopatentowanych informacji praktycznych, wynikających z doświadczenia i badań, które są:
1.    niejawne (nie są powszechnie znane lub łatwo dostępne);
2.    istotne (ważne i użyteczne z punktu widzenia wytwarzania Know-how: ochrona tajemnicy przedsiębiorstwa).

bezpieczeństwo: stan niezagrożenia (s.j.p.)

tajemnica: sekret; też: nieujawnianie czegoś (s.j.p.)

patent: dokument przyznający jakiejś osobie lub firmie wyłączne prawo do czerpania korzyści z wynalazku; też: to prawo (s.j.p.)

informacja: to, co powiedziano lub napisano o kimś lub o czymś, także zakomunikowanie czegoś (s.j.p.)

utwór: każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia (Ustawa)

Dla zapewnienia i sprawdzenia jednoznaczności tego tekstu zbudujmy model pojęciowy (taksonomia i syntaktyka pojęć, przypominam, że nie korzystamy w takich analizach a ontologii, poniższy diagram to nie ontologia):

Warto tu zwrócić uwagę na to, że pojęcie opis patentu pojawia się w taksonomii indywidualizmu treści jak i jej dostępności. Innymi słowy opis patentu jest zarówno utworem jak i treścią nie będącą tajemnicą.
I teraz pytanie: co należy chronić i dlaczego? To zależy…

Patent to monopol, jednak fakty pokazują, że monopole trzeba samemu egzekwować, co nie zawsze jest ekonomicznie uzasadnione, przy założeniu że koszty ochrony patentu nie powinny przekroczyć korzyści z jego posiadania.  I nie mam tu na myśli tylko opłat dla Urzędu patentowego, a potencjalne stałe koszty ochrony z tytułu wytaczanych pozwów cywilnych za łamanie praw patentowych. Rynek pokazuje, że nie raz ochronę patentową można zastąpić ochroną z tytułu praw autorskich (treść opisu jakiegoś rozwiązania to utwór, patrz diagram powyżej) np. wzory przemysłowe, tym bardziej że są rzeczy których nie można opatentować, ale można opisać i chronić właśnie jako utwór (np. logikę oprogramowania).

Know-how

Know-how to kolejny ciekawy obszar, bo wymagający bardzo często ochrony. Patent z zasady jest treścią jawną, podawaną do publicznej wiadomości. Jeżeli ktoś uzna, że jego know-how stanowi o jego przewadze a nie chce czynić z niego patentu, to ma dwa wyjścia: (1) utrzymywać know-how na poziomie trudnym do naśladowania, to się nazywa utrzymywanie bariery wejścia (patrz analiza pięciu sił Portera), albo (2) utrzymywać know-how w tajemnicy przed konkurencją. To kluczowy prawdziwy powód podpisywania umów o zachowaniu poufności (drugi to prawo regulujące dostęp do informacji w spółkach giełdowych).

I teraz jeszcze raz cytowana na początku zasada:

Projekt systemu nie powinien wymagać jego tajności, a ewentualne jego ujawnienie nie powinno przysparzać kłopotów.

I to jest ideał (idealizacja) do prowadzenia analiz. Punktem wyjścia w projekcie powinna być analiza sprawdzająca czy faktycznie ujawnienie danej informacji przynosi szkodę a jeżeli tak, to dlaczego. Dalej: jeżeli know-how stanowi sobą określony mechanizm i jego ujawnienie przynosi szkodę, to faktycznie należy go – jego opis – chronić. Jak? Przede wszystkim taki, precyzyjny, opis musi w ogóle powstać. Jeżeli z jakiegoś powodu nie może być przedmiotem patentu, to pozostaje prawo autorskie. A skoro tak, to: (1) posiadaczem prawa majątkowego do opisu know-how powinien być ten, kto chroni swoje know-how, (2) jeżeli oprogramowanie ma realizować mechanizm stanowiący know-how, to dostawca (wykonawca) tego oprogramowania nie powinien mieć żadnych praw do tego know-how, o ile tylko faktycznie stanowi ono o przewadze na rynku.

Ideał jest taki jak zasada powyżej, wniosek zaś jest taki, że jeżeli o przewadze rynkowej stanowi tajemnica, jej bezpieczeństwo staje się kluczowe. A jak chronić tajemnicę czyli informacje? W ten sam sposób: system opisujący bezpieczeństwo informacji opisuje się procedurami i procesami :), a te właśnie (dokumenty opisujące procesy), zgodnie z zasadą opisaną na początku, nie powinny wymagać ochrony…

Warto na koniec dodać, że na gruncie ustawy o zwalczaniu nieuczciwej konkurencji know-how nabywane przez pracowników IT podlega obowiązkowi ochrony tajemnicy przedsiębiorstwa, który od dnia 4 września 2018 r. został określony jako bezterminowy…

Na zakończenie

Bardzo często jestem pytany o różnicę pomiędzy chronionym utworem a chronionym know-how. Popatrzmy na poniższą mapkę, znaną z książki (i gier) Wyspa Skarbów:

Otóż mapka ta jest chroniona prawem autorskim jako obraz graficzny. Jeżeli prawdą zaś jest, że treść mapki zawiera wiedzę o tym jak dotrzeć do skarbu,  to wiedza ta stanowi know-how piratów i jest trzymana w tajemnicy. Tak więc mapka ta jest utworem niosącym wiedzę o know-how. :). Wystarczająco precyzyjny projekt architektury i logiki działania oprogramowania jest także utworem, niosącym wiedzę o know-how.

A teraz popatrzcie Państwo na swoje umowy z dostawcami oprogramowania… i miejcie ograniczone zaufanie do prawników firm dostawców oprogramowania 🙂 

Dodatek: bezpieczeństwo systemowe znane także jako bezpieczeństwo proceduralne

Klasycznym jego przykładem jest uwierzytelnienie dwuskładnikowe (2FA) czy potwierdzanie double opt-in (model procesu poniżej).

Nawiązując do Zasady Kerckhoffs’a, bezpieczeństwo (metody i narzędzia) nie powinny być tajne (bezpieczeństwo przez zaciemnienie), gdyż wtedy “jedno ujawnienie” niszczy to bezpieczeństwo. Zarówno procedury 2FA jak i opt-in (to tylko dwa z wielu przykładów) nie są tajemnicą, a mimo to nikt nie powie, że ich stosowanie jest niebezpieczne.

Testowanie bezpieczeństwa informacji powinno się odbywać na poziomie procesów biznesowych i procedur. Jeżeli tu istnieją “luki” to żadna technologia szyfrowania i systemy haseł niczego nie zmienia na lepsze ale niewątpliwie podniosą koszty.

MDE to skrót od Model Driven Engineering, nazwy ogólnego trendu w świecie inżynierii.

Od pewnego już czasu  da się zaobserwować, że ludzie i ich umiejętności nie nadążają za złożonością systemów… Nie jest to jakieś wielkie odkrycie, bo problem ten wystąpił w inżynierii maszyn kilkadziesiąt lat temu… mniej więcej w czasie gdy zaczęły się pojawiać pierwsze samochody, potem było już coraz gorzej: liczba detali maszyn idzie w tysiące  (pojazdy) a nie raz i miliony (samoloty pasażerskie, pociągi).

Jedynym sposobem zapanowania nad złożonością obecnych konsytuacji inżynierskich jest redukcja złożoności ich opisów, a możliwe jest to jeżeli zaczniemy tworzyć abstrakcje opisujące wybrane aspekty tych konstrukcji. Jest to także zgodne z podejściem naukowym (ogólna teoria systemów, metodologia nauki), polegającym na generalizowaniu.

W inżynierii od lat stosowane są rysunki techniczne poglądowe, dokumentowanie konstrukcji od ogółu do szczegółu. Po pojawieniu się komputerów osobistych pojawiły się ich – desek kreślarskich – odpowiedniki w postaci aplikacji CAD/CAM.

W inżynierii oprogramowanie notacje, odpowiedniki rysunków technicznych, pojawiły się już w latach 80-tych. Rozwijały się wraz z rozwojem inżynierii programowania i technologii informatycznych. Języki programowania także rozwijają się w stronę coraz wyższego poziomu abstrakcji (od asemblera do języków skryptowych takich jak Pyton czy Ruby on Rails).  Rubikon został przekroczony gdy pojawiły się metody obiektowe w inżynierii oprogramowania i notacja UML (co metodologicznie niemalże zrównało inżynierię oprogramowania z innym obszarami inżynierii).

W konsekwencji w inżynierii oprogramowania na pierwszy plan wysuwa się rola architekta rozwiązania, przed  rolami związanymi z implementacją. Architekt to ktoś kto wie co i po co ma powstać, projektuje rozwiązanie na poziomie abstrakcji ignorującej detale a skupiającej się na cechach użytkowych. Bardzo ważne: architekt nie jest developerem.

W obszarze inżynierii oprogramowania organizacja standaryzująca Object Management Group (OMG.org) opracowała specyfikację MDA (Model Driven Architecture). MDA na tle MDE wygląda tak:

Kluczowy jest tu obszar oznaczony kolorem zielonym (model driven development), to obszar pracy z abstrakcją systemu, pozwalający na dopracowaniu konstrukcji i jej testowaniu, bez konieczności tworzenia realnych prototypów, które są najkosztowniejszą częścią projektów inżynierskich.

Jednym z kluczowych pojęć w procesie tworzenia abstrakcji – modelu – rozwiązania jest pojęcie metamodelu. Metamodel to abstrakcja budowana w oparciu o klasy elementów systemu. jest to dość trudne pojęcie jednak nie raz stosowane intuicyjnie: pisząc w dokumentacji wymagań Faktura najczęściej mamy na myśli wszystkie dokumenty będące fakturą, a nie konkretną fakturę FV/1234/2018. Użycie pojęcia Faktura to nic innego jak nazwanie (wyodrębnienie) klasy dokumentów mających pewne wspólne.

Autor cytowanej prezentacji opisuje także aspekty generowania kodu z modeli, jednak tu osobiście jestem sceptykiem. Wyeliminowanie ludzi z procesu tworzenia kodu jest w moich oczach taką samą utopią jak 100% eliminacja ludzi z procesu tworzenia i realizacji konstrukcji drapaczy chmur czy samochodów.

A teraz zapraszam do lektury cytowanej prezentacji. Co prawda opublikowana w 2013 roku ale nie straciła wiele na aktualności.

https://www.slideshare.net/fraterna/web-technologies-model-driven-engineering?ref=http://it-consulting.pl//?p=15087&preview=true