1

타이토스(Taitoss) - 고성능 블록체인 기술 스택(stack) 버전 1.0 에 기초하여 관광산업에 적용된 분산형 애플리케이션의 사례

Edward Kwon 및 Alex Norta1

1 에스토니아 탈린 기술 대학교 소프트웨어 과학과(alex.norta.phd@ieee.org)

초록. 관광산업은 업계 내의 많은 조직들이 이질적인 프로세스와 기술의 사용으로 인해 매우 분열되어 있다. 또한, 그러한 비균일성은 다양한 명목 화폐의 통용으로 인하여 여행자가 지속적으로 환전해야 할 때 화폐의 구매력이 감소할 정도이다. 결과적으로, 여행을 계획하는 개인은 정보 검색 및 전송을 비롯하여 각 여행지의 평판을 파악하고 항공편, 호텔, 자동차 대여 등 다양한 서비스들을 통합해야 하는 어려움에 직면한다. 이러한 병목 요인들에도 불구하고, 관광산업은 강한 성장세를 보이고 높은 수준의 자동화를 달성할 것으로 예상된다. 여행 및 여행 관련 기술환경(현재 분열 되어있는 서비스들을 자동화하는 여행계획 플랫폼)에는 괴리가 존재한다. 본 논문은 여행 서비스 구성을 위해 스마트 계약을 사용하는 블록체인 기술 기반의 플랫폼인 “타이토스(Taitoss)”를 제시함으로써 그러한 괴리를 해소한다. 더욱 구체적으로 말하자면, 타이토스 플랫폼은 자연어를 처리하고 개인용 여행 패키지 추천 시스템을 제공하기 위한 인공 지능(AI)과 블록체인 기술을 결합한다. 또한, 특정적인 타이토스 토큰의 가용성은 전세계적으로 환전 손실이 없는 편리한 지급 수단을 구현한다.

키워드: 블록체인, 스마트 계약, 토큰, 관광, 고속, 거래

1 서론

여행 및 관광산업은 급성장[5]하고 있으며 이러한 고속 성장세는 지속될 것으로 예상된다. 성장을 저해하는 일부 병목 요인들로 인하여 이질적인 여행 패키지들은 상호 연관성 없이 단편적으로 구성되고 있다. 첫째, 항공사, 호텔, 여행사, 자동차 대여 업체 등 많은 당사자들이 존재한다. 이러한 조직들은 중요한 조정이 이루어지지 않으면 상호 매칭 될 수 없는 다양한 프로세스를 유지한다. 또한, 의미론적 및 구문론적으로 상이한 매우 다양한 기술과 표준[66]이 적용되기 때문에 콘텐츠 공유가 어려워진다. 여행자 계획에 대한 편의성은 지급에 관련하여 다양한 명목 통화의 사용, 신용 카드 결함, 추가적인 정보 공유가 용이한 여행 사이트의 평판에 대한 인식 부족 등으로 인하여 저하된다.

2

관광산업에서 예측되는 동적 성장[5]을 감안할 때, 자동화의 개선을 통해 기존 병목 현상을 극복하는 것이 중요하다 [37]. 이러한 상황에서 P2P(피어-투-피어) 거래가 확대되고 지급을 위해 비트 코인(Bitcoin)[35] 등 암호 화폐가 사용되기 시작하면서 관광산업은 협업 관광으로 변모한다. 동시에, 로봇, 인공 지능(AI) 및 서비스 자동화는 서비스 품질, 관광산업의 경쟁력 강화 및 재무 성과의 향상을 촉진한다. 현재, 여행자가 원하는 관광 서비스의 평판을 추정하는 데에 유용한 다수의 온라인 리뷰 플랫폼이 등장하고 있다 [53, 65]. 최근, 협업 조직과 고객 간의 P2P 참여를 가능하게 하는 분산형 애플리케이션(Dapp) [64] 개발에 관련하여 블록체인 기술[15]은 암호 화폐 부문뿐만 아니라 다른 부문으로도 적용을 확대하고 있다. 그러한 블록체인 Dapps 가 관광 패키지 구성의 자동화 및 서비스 품질 수준을 크게 변경하는 데에도 유용하다는 인식이 확대되고 있다[17, 47, 49, 50]. 마지막으로, AI 영역의 최근 발전은 타이토스(Taitoss) 플랫폼에 적합한 자연어 처리[24, 27]의 상당한 발전으로 이어지고 있다. 이러한 인공 지능 개발은 멀티미디어 측면의 수용을 위해 타이토스 플랫폼에 적용 가능한 다양한 유형의 추천 시스템에도 유용하다[52, 67, 68].

이러한 기술 현황을 보면 전세계 관광산업은 시간과 비용의 비효율을 극복하기 위해 인공 지능과 고성능 및 확장 가능한 블록체인 기술의 결합을 요구하는 매우 복잡한 대규모 시스템임을 알 수 있다. 그러나 성능 및 확장 가능성에 대한 요구사항을 충족시키기 위한 블록체인 기술과 AI 간의 차별화된 통합에 관련해서는 괴리가 존재한다. 이 백서는 인공 지능 수단으로 지원되는 고속 블록체인에 매핑된 “여행 알선 거버넌스(governance) 생애주기”에 다양한 이해 관계자를 통합하는 ‘사회-기술적 플랫폼”을 통해 여행 산업의 요구사항을 어떻게 충족시킬 수 있는지를 묻는 질문에 대답함으로써 그러한 괴리를 해소한다. 관심사의 분리를 위해, 우리는 다음과 같이 3 개의 하위 질문을 추론한다: 1) 전세계 여행 산업에 대한 특정 요구사항 집합은 무엇인가? 2) 사회-기술적 여행 플랫폼의 아키텍처는 무엇인가? 3) 다양한 이해 관계자들을 관여시키는 여행 서비스 알선을 위한 거버넌스(governance) 생애주기는 무엇인가?

본 백서의 나머지 부분은 다음과 같이 구성된다. 2 절에서는 관광산업의 현황에 관련하여 현재의 사례를 제시한 후에 예비 조사를 실시한다. 3 절에서는 이해 관계자를 관여시키는 “목표 모델”의 형태로 타이토스 관광 플랫폼에 대한 요구사항을 제시한다. 다음으로, 4 절에서는 구성요소와 이해 관계자 간의 정보 교환을 관여시키는 “목표 모델”에 대하여 분산형 시스템 아키텍처를 추론한다.

5 장에서는 타이토스 플랫폼 아키텍처의 구성요소 및 독립체(entities)의 동적 교환 프로토콜에 포함된 관련 “온-체인(on-chain)” 거래 세트를 제시한다.

6 장에서는 기존의 블록체인 기술 스택을 통해 타이토스 플랫폼을 신속하게 전개하는 것에 대한 타당성 평가를 제시한다. 마지막으로, 7 장은 본 백서를 마무리하고 향후의 과제를 제시한다.

3

2 동기 부여적인 실례 및 예비적인 내용

2.1 절은 관광산업의 현황에 관련하여 현재 진행 중인 간단한 사례와 함께 내재적인 문제에 대한 설명을 제시한다. 다음으로, 2.2절은 후속적인 절에 관련된 예비적인 내용을 제시한다. 또한 2.2 절에서는 타이토스 플랫폼의 향후 자동화 전망에 대한 개념적 설명과 함께 후속적으로 다룰 모델링 표기(법)에 관한 개요를 설명한다.

2.1 동기 부여적인 실례

그림 1 의 예는 휴일 여행을 계획하고 있는 가족을 중심에 보여준다. 전체적인 예약은 예약 주체인 가족이 “상호 연계되지 않은 여행-서비스 제공업체들”이 관여된 정보 비대칭에 직면하는 단편적인 절차이다.

그림 1: 관광 업계의 현황

그림 1 의 가장자리는 시계 방향으로 3 개의 여행 서비스 업체 및 항공권 구매와 자동차 대여를 알선하는 파트너 D 를 각각 보여준다. 파트너 X 는 호텔 예약을 알선하고 파트너 Q 는 휴가 기간 동안 스키 패키지, 온천 치료요법 및 아동을 위한 실내 놀이 공원 등 엔터테인먼트의 예약을 알선한다.

가족이 몇몇 국가를 연속적으로 방문하기로 결정하는 경우 상기 3 개의 각 파트너들이 몇 개의 장소에 대하여 그러한 예약을 알선한다고 가정할 때, 복잡성은 증가할 수 있을 것이다. 따라서, 여행에서 가족은 연속적인 환전을 통해 몇몇 명목화폐(fiat currency)를 확보해야 하므로 결과적으로 환전 손실, 신용 카드사 수수료, 은행 수수료 등이 발생한다. 관광-서비스 부문의 현황에 관한 제 1절의 논의를 고려할 때, 여행, 숙박 및 엔터테인먼트에 대하여 그림 1 에 제시된 3 개 요소들의 예약은 시간이 많이 소요될 것이다. 또한, 가족은 서비스와 비용 간 최선의 트레이드오프(tradeoff)가 이상적인지를 알 수 없을 것이다. 서비스는 다양한 제공자들로부터 구매되므로, 각 서비스가 ‘복잡한 여행 목표’에 부합하도록 보장하는 것은 쉽지 않다.

Business Network Model

Service Type B ini o

d Role A out i out Role C oClou Service Type A Role B Service Type C

inin

e-HUBi o

ch i o

Servicch

iService Offer B

o chinout

Service Offer A outService Offer C

ini o Partner X oi

Partner D Partner Qorc rate

System Infrastructure

4

2.2 예비적인 내용

예비적인 내용을 제시하기 위해, 그림 2 는 원활한 서비스 매칭과 상호작용을 위한 서비스-허브(Service-HUB)[43]를 나타내는 외부 층을 제시하는 동시에 함께 ‘자동화된 관광-서비스 생성 시나리오’에서 도출 및 조정된 개념적 예[36]를 제시한다. 이러한 층은 서비스 소비자들과 서비스 제공자들에 대한 분할(partition)을 통해 추가적으로 개선된다. 서비스 제공자들은 서비스 요청에 부합되는 서비스를 제안하기 위해 경쟁한다. 그림 2 는 자동화되고 마찰이 없고 통합된 방식으로 그림 1 의 여행-서비스 예약을 생성하는 서비스 제공자들을 포함시켜 단순화된 시나리오를 제시한다. 인용[19,39]에 제시된 것처럼, 정식적인 관점으로 볼 때 그림 1 의 협업 모델은 많은 당사자들에 대하여 확장 가능하다.

그림 2: 타이토스 여행-주선 플랫폼에 대한 자동 시나리오 [36].

구체적으로, 그림 2 에 관련하여 프로세스를 인지하고 있는 “탈중앙화된 자율 기관들”(DAO) [12]에 의하여 여행-서비스 제공이 발생한다고 가정할 수 있다. 원활한 여행-서비스 제공을 위한 청사진은 사업 네트워크 모델(BNM)이다. 후자는 여행-서비스 제공을 위한 연출을 구체화하며 추가적으로 템플릿 계약을 포함하고 있는데 이러한 템플릿 계약은 역할이 할당되어 있고 프로세스 인지에 입각한 서비스 유형에 관한 것이다. 서비스 유형은 그림 2 에서 생략된 파트너들이 내부적으로 보유한 대규모 사내 프로세스의 하위 프로세스 관점을 제시하는 서비스 제안에 부합해야 한다고 가정된다[18]. ‘프로세스 관점’ 또는 (동의어로 사용되는 용어인) ‘서비스 제안’은 서비스 제공 파트너들의 정체성, 서비스 및 평판 등에 대하여 신속하고 반자동적으로 파악할 수 있게 한다.

5

그림 2 의 외부 연출 층에서, 서비스 제안은 BNM 에 포함된 서비스 유형에 대하여 부합한다. 또한, 파트너는 각 서비스 유형의 역할에 부합해야 한다[18].

그림 2 의 하단에서, 층은 고급 서비스 프로세스를 매핑하는 블록체인 기술 및 스마트 계약을 보여준다[62]. 간략하게 말하자면, 스마트 전자 계약[58]은 “탈중앙화된 자율 기관들”(DAO)들 간의 사업 거래를 규정한다. 스마트 계약은 동의에 입각한 스마트 계약의 사실 추적 기능으로 ‘부인방지(non-repudiation)’ 및 ‘불변 추적성(immutable traceability)'을 구현하는 블록체인 기술 층[35]에서 계약 조건을 이행하는 전산화된 거래 프로토콜[57] 이다. 따라서, 블록체인은 협업 사건의 발생을 포착하고 “암호 다이제스트(cryptographic digest)”에 따른 해시(hash) 가치에 대하여 인공물 소유 체인을 독립적으로 검증하기 위한 분산형 데이터베이스이다. DAO 협업을 위해, 서비스 중심적 클라우드 컴퓨팅(SOCC) [63]은 그림 2 하단에 제시된 이질적인 레거시 시스템 인프라의 조직 및 연출[42]을 위해 정보 및 비즈니스 프로세스 흐름[20]의 원활하고 즉석적인 통합과 조정을 촉진한다.

타이토스(Taitoss) 시스템의 설계를 위해, 다양한 모델 중심적 설계(MDD)[4]를 적용하는 특정 방법론이 적용된다. 이러한 접근법의 목표는 우선 백서의 시스템 설계 프로세스를 강조하는 것이다. 이러한 기반을 토대로 하고 후속적인 ‘딥 엔지니어링(deep-engineering)’ 주기에 기초하여, 타이토스(Taitoss) 플랫폼의 신속한 구현 및 전개가 가능하다. 일련의 체인형 모델을 생성함으로써 1) 각 플랫폼 기능에 대한 이해관계자들의 관계, 2) 정보 교환을 통해 도출된 아키텍처 토폴로지에 대한 이해관계자들의 관계, 3) 이해관계자들과 타이토스(Taitoss) 플랫폼 구성요소 간의 역동적인 교환 프로토콜 내에서 블록체인 거래의 위치에 대한 이해관계자들의 관계에 관련하여 타이토스(Taitoss) 플랫폼에 대한 이해를 증진할 수 있다.

목표-모델[56]은 시스템의 요구사항을 우선적으로 묘사한다. 둘째, UML 구성요소 도식[21]은 정보 교환을 통해 정적 아키텍처 토폴로지를 대략적으로 보여준다. 셋째, 제한적인 일련의 비즈니스 프로세스 모델링 표기(notation) BPMN [46]를 통해 타이토스(Taitoss) 플랫폼의 역동적 거동을 위해 블록체인 상에서 저장되어야 하는 주요 사건의 할당이 구체적으로 제시된다.

목표 모델은 9 개의 상이한 모델 표기로 구성된 에이전트 중심적 모델링(AOM) 방법의 일부분이다[56]. 인위적 소프트웨어 에이전트는 내부 지식인 맥락에 따라 사건을 인식하는 센서로 구성하고 지식 기반을 통해 향후 발생될 사건에 대하여 내부적인 컨트롤러 논증 기준이 되는 분류 체계에 따라 사건을 형성한다. 컨트롤러(controller)가 일련의 조치(action)들에 대하여 결정할 때 그러한 조치들은 에이전트의 맥락에 따라 액추에이터(actuator)를 통해 투영된다. 목표 모델에 기초하여, 추론된 UML 구성요소 도식[6]은 타이토스(Taitoss) 플랫폼의 정적 구조를 구체적으로 제시한다. 그림 3(b)는 라벨이 표시된 사각형 구성요소를 통해 구성요소 도식 요소를 보여준다. 하나의 구성요소는 중첩된 하위 구성요소로 구성될 수 있으며 정보 교환을 구체적으로 제시하기 위해 “제공되거나 요구된 인터페이스”가 할당된다.

6

그림 3: 차후적으로 사용되는 모델링 표기

제공된 인터페이스 그림 3(b)은 하나의 원을 가진 선이다. 요구되는 인터페이스들은 끝부분에 컵이 하나 있는 선들이다. 액터(Actor)들은 타이토스(Taitoss) 플랫폼의 구성요소들과 상호작용하며 목표 모델에서 ‘역할’과 동일한 의미를 갖는다. BPMN 모델을 통해, 타이토스(Taitoss) 플랫폼의 역동적인 관리 행동을 구체적으로 제시될 것이다. 그림 3(c)은 본 백서에서 고려되는 BPM 의 제한적인 하위 집합을 보여준다. 일반적인 출발 요소(start element)는 흰색으로 채워진 원으로 제시된다. 생애주기는 원이 마침내 검정색으로 채워지면서 종료된다. 생애주기 내에서 원자적 과제(atomic tasks)는 더 이상 분해될 수 없다. 플러스(+) 표시가 있는 둥근 사각형은 더 낮은 수준의 요소들로 분해 될 수 있는 비(非)원자 하위 프로세스이다. 방향 표시된 원이 있는 하위 프로세스는 특정적인 출구 조건이 충족될 때까지 계속 진행되는 처리 루프(processing loops)를 나타낸다. 방향 표시된 원호(arc)는 그림 3(c)에서 제시된 요소들을 연결한다. 디지털 객체로 부분적으로 표시된 원호는 하나의 요소에서 다음 요소로 전달된다. 마지막으로, 그림 3(c)은 “OR(또는)”를 통한 분할 및 결합에 대하여 배타적인 게이트웨이(gateway)가 되는 제어-흐름 요소를 보여줄 뿐만 아니라 “AND(그리고)”릍 통한 분할 및 결합에 대하여 평행 게이트웨이가 되는 제어-흐름 요소를 보여준다. 또한, 제어-흐름이 분할되고 다시 결합되는 동안 몇 개의 평행 분기(branches)가 선택 가능할 때 포괄적인 게이트웨이(inclusive gateway)가 되는 제어-흐름 요소를 보여준다. 하나의 분기가 선택되면, 포괄적 게이트웨이는 배타적 게이트웨이와 일치하며 모든 분기가 선택되면 포괄적 게이트웨이는 평행 게이트웨이와 일치하는 사실에 유의해야 한다.

3 타이토스(Taitoss) 플랫폼에 대한 목표 모델

이전 절에서 언급한 현재 진행중인 사례에서는 관광 산업의 현재 운영 방식의 단점과 한계점을 해소하기 위해 타이토스(Taitoss) 플랫폼이 제안해야 하는 기능을 추론한다. 타이토스(Taitoss) 플랫폼은 여행자 및 관광 관련 기업이 일련의 중앙화된 데이터베이스 보다는 분산형 원장에 협업 관련 정보를 저장할 수 있게 함으로써 상기에 언급된 단점과 한계점을 해소한다. 또한, 타이토스 플랫폼은 불필요한 여행 비용을 생성하는 제 3 자 중개인 및 구성된 서비스 제공의 지연을 초래하는 제 3 자 중개인을 제거한다. 타이토스 플랫폼에 대한 주요 요구사항은 아래와 같다:

7

• 타이토스 플랫폼 관리: 여행-서비스 구성을 설정하기 위한 템플릿은 모집단에 대하여 함께 관리되어야 한다. 이러한 템플릿에 대하여 등급 및 분석 내용은 결과를 뒷받침하며 최종적으로 플랫폼에서 토큰이 관리되어야 한다.

• 온보드 사용자(Onboard users): 이 기능은 사용자의 등록 및 고객확인(KYC) 절차의 실행을 관여시킨다.

• 여행-알선 템플릿 작성: 템플릿 선택과 정책, 서비스, 파트너 등의 추가를 가능하게 한다.

• 실제적인 알선 준비: 수락 또는 거부 시에 협상 및 평가되어야 하는 요청에 대하여 제안을 매칭한다.

• 여행 알선 확립: 차후적으로 실행되는 여행 알선에 대한 지급을 관여시킨다. 여행 알선은 위반에 비용의 회수를 위해 다양한 정도의 롤백(철회)을 통해 평가 및 모니터링 되어야 한다.

• 계약 종료: 여행-서비스 알선에 따라 잔존하는 복잡함이 해소될 수 있도록 적극적인 정책, 서비스, 역할의 단계적 제거와 모니터링을 요구한다. 종료가 주의 깊게 이루어지지 않으면, 잔존하는 프로세스와 데이터는 컴퓨팅 능력(연산 능력)를 상당히 감소시킨다.

• 토큰화된 거래: 타이토스 AI 토큰((TAI 토큰)은 시스템 내에서 모든 지급과 거래에 사용되는 타이토스 크레디트(TAIC)의 구매를 원활하게 한다. 토큰화된 시스템의 사용은 즉석 거래, 소액 결제, 해외 송금, 최소 거래 비용 등의 형태로 많은 이득을 가져온다,

우리는 타이토스 시스템의 요구사항을 정의하기 위해 2.2절에 설명된 목표 모델을 사용하여 타이토스 플랫폼의 기능적 목표와 품질 목표에 집중한다. 따라서, 3.1절은 기반이 되는 가치 명제를 포함한 최상위 목표 모델, 여행 알선 시스템에 대한 최우선적인 개선 기능 목표 및 품질 목표, 추가적으로 할당된 역할로 구성된다. 차후적인 절들은 기능적인 목표에 대한 하위 수준의 개선을 제시한다..

3.1 일차적인 AOM 목표 모델

그림 4 의 중앙은 평행 사변형으로 묘사된 타이토스 플랫폼의 가치 명제를 보여주는데, 타이토스 플랫폼의 가치 명제는 앞 절에서 언급된 우려를 경감시키고 여행자에게 이득을 가져다 주고 제 3 자 중개인을 제거하려는 “관광-서비스 알선 플랫폼 제공”으로 표시되었다. 위계적으로 아래에는 각각 ‘클라우드’로 묘사된 일련의 상위 수준 기능 목표 및 각 품질 목표가 열거되어 있다. 개선적인 기능 목표(refining functional goals)는 관리자 플랫폼, 온보드 사용자(onboard user), 알선 템플릿 작성, 알선, 알선의 준비 등에 관련한다. 이러한 상위 기능 목표에 관련된 역할들은 그림 4 에 강조되어 있고 머리 아이콘(head icon)으로 묘사되어 있다. 이러한 하위 기능 목표는 아래에서 최상위 모델의 품질 목표가 설명될 때 추가적으로 정의된다. 정의 기능 목표에 관련된 품질 목표는 3.2절에 구체적으로 제시되어 있다. 개선 기능-목표 트리(tree)의 상속 라인(inheritance line)을 고려할 때, 그림 4 의 가치 명제에 관련된 품질 목표는 모든 하위 수준 기능 목표에 관련된다.

8

Performant

Seamless

Observable Available

Secure Convenient

Provide

Friction-less

Flexible

Usable

Reliable Verifiable

Fast

a tourism-service arrangement platform

Integrable SymmetricFast

Scalable Interoperable Maintainable Incentivized

Manage Platform Onboard users Populate arrangement templates

Service Provider

Create arrangementEnact and prepare

arrangementService Provider

Taitoss

TouristTourist

그림 4. 최상위 타이토스 플랫폼 요구사항

가용성은 타이토스 플랫폼에 관련된 역할 별로 사용자가 모든 기능을 이용 할 수 있음을 의미한다. 또한, 구성요소의 그러한 가용성은 다른 연결된 내부 또는 외부 구성요소들에 대하여 상당히 보장되어 있다. “원활성”은 역할 및 구성요소가 정보 처리를 요청할 때 타이토스 플랫폼에 저해적인 지연이 없다고 가정한다. “성능 기준 부합성(performant)”은 잠재적으로 몇 개의 제공자들을 관여시키는 여행 알선의 어셈블리와 관리를 위한 연산 및 의사소통 제약이 적음을 의미한다. “보안(security)”은 타이토스 플랫폼 상에서 공유되는 정보의 무결성, 가용성 및 기밀성이 항상 보장되는 동시에 이해관계자의 정보 접근 권리가 보장됨을 의미한다[3]. 또한, 알선 서비스를 무단으로 사용 및 거부하려는 시도에 대하여 저항하는 능력이 보장되며 평판이 좋은 신뢰적인 제공자에게는 플랫폼이 지속적으로 제공됨을 의미한다. “편의성(convenient)”은 타이토스의 모든 기능들이 여행 알선 서비스에 관련하여 역할의 필요(니즈), 활동 및 계획을 충족 및 이행의 측면에서 해당 역할에 대하여 사용자의 만족스러운 경험을 보장할 필요가 있음을 의미한다. “무마찰(frictionless)”은 정보의 의미 및 구문이 구성요소에 대한 올바른 입력 역할을 하는 형식으로 되어 있음을 의미한다. 또한, 구성요소 기능에 대한 요구는 표적 구성요소의 교착을 초래할 수 있는 정보 입력 누락 또는 잘못된 형식의 정보를 허용하지 않는다. “사용 가능성”은 타이토스 플랫폼이 예상한대로 “원 핸드 기능(one hand functioning)”을 수행함을 의미할 뿐만 아니라 모든 관련된 역할들이 “제공된 플랫폼 기능”의 의미를 이해하고 있으며 그 기능을 여행 알선 서비스를 위해 사용할 수 있음을 의미한다. “유연성”은 타이토스 플랫폼이 여행자 및 서비스 제공자들의 니즈(needs)가 매우 다양함을 고려하도록 보장한다. 따라서, 플랫폼은 다양한 협업 시나리오를 감안해야 하며 알선 시에 기술적으로 이질적인 서비스들의 활용을 고려해야 한다. “신뢰성”은 신뢰적인 정보 및 여행 서비스의 제공을 위해 관련 역할들이 신뢰할 수 있는 “일관적으로 우수한 서비스 품질과 성능”이 타이토스 플랫폼에서 제공함을 의미한다.

9

3.2 AOM `목표-모델 개선

그림 5 의 묘사는 타이토스 플랫폼을 관리하고 사용자를 온보딩(onboarding)하기 위한 기능적 목표의 개선을 보여준다. 플랫폼 관리를 위해 모든 기능 개선 목표를 계승하는 두 가지의 추가적인 품질 목표가 관련되어 있다. 품질 목표에 관한 관찰 가능성은 상태 차이가 발생할 때 관련 목표에 대하여 플랫폼 관리가 뚜렷하거나 인식 가능함을 의미한다. 또한, 품질 목표에 관한 확장성은 플랫폼 관리 시에 템플릿의 동시 누적 및 조작, 토큰 관리, 경쟁적 환경 제공 및 토큰 관리가 고려됨을 의미한다. 품질 목표인 확장 가능성은 많은 사용자가 동시에 등록되어야 하고 KYC 절차가 수행되어야 하는 사용자의 온보딩(onboarding)에도 대해서도 적용된다. 또한, 다수의 사용자가 등록하더라도 대기 시간이 없어야 하므로 사용자 온보딩은 신속히 이루어져야 한다.

Tourist

ObservableScalable Fast

Manage Platform Onboard users

Manage templates

Create template

Update template

Remove template

Taitoss Register user

Conduct KYC

Service Provider

Provide competitive environment

Manage ratings and analytics

Manage trust and reputation

Store populated templates

Manage tokens

Send/receive tokens

Exchange tokens

TAI/TAIC

Burn/mint TAIC tokens

TAIC

그림. 5: 타이토스 플랫폼 및 온보딩 사용자의 관리를 위한 개선 목표 모델

그림 5 의 역할은 플랫폼 관리 및 사용자의 온보딩과 관련된 Taitoss 를 나타낸다. 또한, 여행 관광객 및 서비스 제공 업체는 온보딩 사용자의 기능 목표에 관련되어 있다. 그림 5 의 토큰 관리에 관련하여 토큰 교환 및 토큰을 보내고 및 수령하는 것은 TAI 및 TAIC 토큰을 관여시킨다. 토큰을 소각(burning) 및 생성하는 경우, TAIC 만 고려된다. 그림 6 에서 여행사의 작성은 여행자 역할을 모든 기능에 관련시킨다. 이와 마찬가지로, 서비스 제공자는 여행-알선 템플릿 작성에 관련된다. 인위적인 에이전트 권유자(recommender)는 여행 알선 템플릿을 선택하여 인간 에이전트(human agents)를 지원한다. 또한, 그림 6 에 제시된 세 가지 품질 목표는 모든 개선 기능 목표에 적용된다. “유지 가능성”은 Taitoss 플랫폼의 가동 시간에 수정 및 수리될 수 있는 여행 알선 기능의 능력에 관련된다. “인센티브화(incentivized)”는 인센티브가 제공될 때 모든 관련된 역할들이 동기 부여되고 어떤 일을 하도록 권장되어야 함을 의미한다. “상호 운영성”은 인터페이스 프로토콜에 부합하고 개별적으로 개발 및 통합된 구성요소들에 접근할 수 있도록 여행 알선을 실시하는 기능을 의미한다.

10

Tourist

MaintainableIncentivized interoperable

Populate arrangement templates

Service Provider

Select template

TAIC

Define policies<Agent>

Recommender

Define specifications

Formulate conditions (non-negotiables)

Formulate negotiable preferences

Complete

그림 6. 여행-알선 템플릿 작성을 위한 개선 목표 모델

그림 6 의 개선 기능 목표에 관련하여, 여행자 및 서비스 제공업체가 준비된 여행-알선 템플릿을 선택하면 TAIC 토큰에 의한 현금화가 이루어진다. 이 템플릿은 여행 알선의 필수적인 부분인 의무 및 규칙[45]으로 구성된 정책으로 채워진다. 사양의 정의는 프로세스를 인식하는 여행 서비스에 중점을 둔다. 우리는 이러한 서비스가 후속적인 알선 시에 진화 가능하도록 조직 전반적으로 구성되어 있다고 가정한다[19]. 또한, 정의된 사양과 함께 협상 불가능한 정형화된 조건 및 정형화된 협상 가능한 환경설정에는 관련 품질 목표 “완료(Complete)”가 있는데, 이는 이 세 가지 알선 관련 요소들이 법적 관련성을 충족시키기 위해 모든 요소들을 포함해야 함을 의미한다.

그림 7 에서와 같이 알선의 생성을 위해, 몇 가지 품질 목표들이 이러한 일차적인 수준의 개선에 직접 할당된다. “통합 가능성”은 인터페이스 프로토콜이 부합해야 하는 구성요소로서 별도로 개발 및 통합된 구성요소인 여행-서비스 알선을 의미한다. “대칭”은 템플릿의 서비스 유형 및 여행-서비스 제공이 동형으로 부합하거나 매우 유사하게 부합함을 가정한다. 마지막으로, 품질 목표 신속(Fast)은 관련 역할들에 대한 상당한 지연 없이 “기능이 모두 향상된 알선’이 발생함을 의미한다. 관광객 및 서비스 제공자의 역할은 그림 7 의 일차적인 개선에 할당되므로 관련된 모든 기능 개선 목표에 관여된다.

Tourist Service Provider

Integrable

Symmetric

FastCreate arrangement Transparent

<Agent> Arrangement

Broker

Match arrangement offers/requests

TAIC

Evaluate matches

Select best offer

Negotiate arrangement Scalable

Merge specifications

Merge and negotiate preferences

Highly- Automated

Resolve conflicts

Manage counter offers

Define monitoriabillity constructs

<Agent> Rollback agent

Accept arrangement Create arrangement

contract

Reject arrangement

Rollback

Complete

그림. 7: 여행 알선을 위한 개선 목표 모델

11

그림 7 의 추가적인 품질 목표는 개선 목표에 할당된다. 여행 알선 시에 제안과 요청의 측면에서 서비스를 투명하게 매칭하는 것은 해당 역할에 관련하여 동형 또는 매우 유사한 매칭이 불가능한 측면을 보아야 함을 것을 의미한다 [19]. 품질 목표로서 “확장 가능성”은 여행 알선에서 제안과 요청 간 매칭의 평가에 관련된 개선 기능과 이러한 알선의 협상 과정에 관련된다. 후자는 여행-서비스 사양을 병합하고, 해결되어야 하는 충돌을 유발할 수 있는 여행 환경 설정을 병합 및 협상하고, 후속적으로 발생하는 반대 제안(counteroffer)을 관리하고, 여행이 제공되는 특정 조건에서 서비스 소비자가 관찰을 할 수 있게 하는 모니터링 가능성 구성을 정의하는 기능으로 더욱 개선된다[40]. 이러한 기능 중에서 고도로 자동화된 기능은 여행-서비스 사양을 통합하고 충돌을 유발할 수 있는 여행 환경 설정을 병합 및 협상 하는 것에 관련된다. 이러한 높은 수준의 자동화를 보장하기 위해 “알선 브로커(Arrangement Broker)”라는 인위적인 에이전트는 알선되는 제안 및 요청 간의 매칭에 관여될 뿐만 아니라 환경 설정의 병합 및 협상과 충돌 해결에 관여되어 있다. 품질 목표로서 “완성”은 여행자 및 서비스 제공업체의 여행 서비스 알선에 대한 수락을 “합법적으로 관련성 있는 결과가 가능한 지점”까지 개선하는 알선 계약의 생성에 할당된다. 마지막으로, 알선의 거부를 개선하는 롤백(철회) 기능은 “롤백 에이전트(Rollback Agent)”라고 명명되는 인위적인 에이전트를 통해 지원된다.

그림 8 의 알선을 준비 및 실연하는 “기능적 목표”는 3 개의 하위 수준의 기능적 개선 분기(refinement branches)로 구분된다. 최상위 수준에는 관광객 및 서비스 공급업체에 관련된 역할이 있다. 또한 모든 준비 및 실연 중인 여행 알선은 검증 가능해야 한다. 즉, 제어 흐름 [19], 데이터 흐름, 리소스 관점 등과 같은 측면의 건전성은 도구 지원 알고리즘 검사를 통해 보장되어야 한다.

<Agent> Arrangement

terminatorTourist Service Provider

<Agent> Preparation agent

Enact and prepare arrangement Verifiable

Terminate arrangementEnact arrangement Prepare arrangement

Remove policies

Remove/terminateservices/contracts

Remove roles

Remove monitors

Pay arrangement

Execute arrangement

Rate/Review arrangement

Monitor violations

Prepare services

Prepare contracts

Prepare policies

Prepare monitors

Recover from violations

Monitor modification requests

Manage changes and modifications

<Agent> Rollback agent

Highly- Automated Rollback

TAIC

그림 8: 여행 알선의 준비, 실연 및 종료를 위한 개선 목표 모델

12

그림 8 의 알선 준비를 위한 개선 기능은 관광객의 실연(實演, enactment) 관찰 가능성(enactment observability)을 조정하는 모니터링뿐만 아니라 의무 및 권리로 구성된 정책과 함께 계약에 추가되는 여행 서비스의 준비를 조정하는 준비 에이전트의 지원을 관여시킨다. 알선의 실연(enactment)를 위한 모든 개선 기능은 여행 알선의 실연 및 지급, 여행 알선에 대한 검토와 평가, 위반과 변경 요청에 대한 모니터링, 위반으로부터의 회복, 변경/수정 및 롤백(철회)에 대한 관리를 포괄하는 TAIC 토큰을 통해 현금화를 수행한다. 후자의 기능을 위해, 전용 롤백 에이전트(Rollback Agent)가 지정되어 높은 수준의 자동화가 보장된다. 마지막으로, 여행 알선의 질서 정연한 종료는 고도로 자동화되어 있는데, 이는 알선 종료자(Arrangement Terminator)라고 명명되는 에이전트의 할당을 고려해야 하는 이유가 된다.

알선 종료를 위한 개선 기능은 여행 알선이 “여행-서비스 제공”의 질적 수준에 대한 로그를 제외하고 여행 알선이 완전히 제거되는 지점까지 정책, 계약 서비스, 역할 및 모니터를 제거하는 것이다.

134 분산 아키텍처 모델 및 데이터 교환

타이토스 플랫폼은 일련의 제한적인 휴리스틱 매핑에 입각한 목표 모델에서 도출된다. 따라서 4.1 절에서는 목표 모델에서 구성요소 도식 표기에 이르는 휴리스틱 매핑을 논의하며 4.2 절에서는 타이토스 플랫폼 아키텍처를 설명과 함께 구성요소 도식으로서 보여준다.

4.1 휴리스틱(Heuristics) 매핑

위의 목표 모델에서 구성요소 도식을 추론 할 때, 휴리스틱 매핑 집합은 다음과 같다. 목표 모델의 가치는 전체 시스템 아키텍처를 제안하는 반면에 첫 번째 개선 수준의 기능적 목표는 그림 9 의 최상위 구성요소로 매핑 된다. 각각의 이차적인 개선-수준 기능적 목표는 중첩된 구성요소 안으로 매핑 된다. 공간 제한으로 인하여 타이토스 플랫폼 아키텍처의 더 낮은 수준의 기능적 목표는 고려되지 않는다. 다음으로, 목표 모델 역할 연관성에 기초하여 어떤 구성요소 액터(actor)가 할당되어야 하는지를 도출한다.

구성요소 도식 안에서 인터페이스를 수신 및 제공함으로써, 액터(actor)와 구성요소 간의 정보 교환 방향이 표시된다. 이러한 정보 교환은 액터(actor)가 타이토스 플랫폼에서 사용할 수 있는 “애플리케이션-프로그래밍-인터페이스(API)”로 구현된다. 또한, 그림 9 의 아키텍처 구성요소 간 정보 교환은 인터페이스 수신 및 제공으로 설명된다. 인터페이스 교환에 할당된 추상 라벨(abstract label)은 복잡한 유형의 데이터 객체를 개념적으로 표현한다. 또한, 토큰화(tokenization)를 나타내는 목표 모델의 “회색 음영 영역”은 “회색 음영 처리”된 구성요소에 의하여 아키텍처 안으로 동일하게 매핑 된다. 품질 목표는 본 백서가 집중하는 사안이 아닌 아키텍처 스타일 및 패턴[42] 등의 경우처럼 시스템 구현 시에 실현되므로 그림 9 의 구성요소 도식에 직접 매핑 되지 않는다.

4.2 구성요소 도식

그림 9 의 타이토스 플랫폼은 이 절에서 휴리스틱 매핑을 적용한 결과를 보여준다. 인터페이스 제공 및 수신에 따른 정보 흐름은 목표 모델이 표현할 수 없는 추가 사항이므로 주로 이 설명에 초점이 맞춰진다. 우선 각 구성요소와 액터(actor) 간의 정보 교환을 설명한 후에 구성요소들 간의 정보 교환을 설명한다. 간략하게 말하자면, 임베디드 구성요소들 간의 정보 교환은 본 백서가 집중하는 내용에서 벗어난다.

14

Tourist/Service Provider

KYCdata

Taitoss

Profile data

KYCdata

Approval/ Rejection

User On-Boarding Manager

User registration

portal

KYC Manager

User Manager

User profile

Template selection

TAICtokens

Policies

TemplateTemplate Population

Manager

Template Selection Manager

Wallet

Policy Manager

Policies

Template specifications

Platform Manager

Template Manager

Template

Specifications

Conditions

Specification Manager

Condition Manager

Specifications

Conditions

Template Storage

Token Manager

Wallet

TAICtokens

Arrangement Manager

Arrangement Matching Manager

Wallet

Arrangement Negotiation Manager

Template

Ratings & Analytics Manger

TAICtokens Best

Offer Selector

Ratings and analytics data

Preparation- and Enactment Manager

Wallet

Arrangement Preparation

Arrangement information

Match

Evaluator

ArrangementAcceptance/Rejection

Manager

Proposed Arrangement Information

Manager

Arrangement Enactment Manager

Enactment

Acceptance/Rejectiondecision

Termination Manager

그림 9: UML 구성요소 도식으로 제시된 타이토스(Taitoss) 플랫폼 아키텍처

그림 9 의 아키텍처는 기능적 목표 모델의 1 단계 개선에서 도출된 5 개의 최상위 구성요소들을 보여준다. 여기에서는 기능 목표의 두 번째 개선 수준으로부터 매핑되는 중첩된 구성요소들이 삽입된다. 좌측 상단에서, 사용자 온보딩(onboarding)을 관리하기 위한 구성요소는 현금화 보다는 KYC 및 사용자 관리자에 관련된 “사용자 등록 포털”인 임베디드 구성요소를 포함한다.

그림 9 에서 3 개 액터는 사용자 온보딩(onboarding)을 관리하기 위한 구성요소와 상호 작용하는 관광객 및 여행-알선 서비스 제공업체인 타이토스 이다. 구성요소들과 교환된 데이터 객체가 관광객 및 서비스 제공자 모두에 대하여 교차함에 따라, 관광객과 서비스 제공자가 하나의 액터로 병합된다. 따라서, 여행자 및 서비스 제공업체는 사용자 등록 포털을 통해 KYC 처리 및 프로필 정보에 대한 데이터를 제출한다. 또한, 타이토스는 KYC 데이터를 최초 확인한 후에 관광객 및 서비스 제공업체의 신청에 대하여 승인 또는 거절한다.

15

그림 9 의 우측 상단에 있는 템플릿-작성 관리자 구성요소는 현금화되는 여행-알선 템플릿 및 토큰 지갑의 선택을 관리하기 위한 임베디드 구성요소로 구성된다. 나머지 3 개의 임베디드 구성요소는 정책, 여행-서비스 사양 및 조건을 관리하기 위한 것이다. 관광객 및 여행-서비스 제공업체는 적합성 여부를 먼저 확인한 후 템플릿을 선택한다. 또한, 두 액터(actor)는 해당 임베디드 관리 구성요소에 대하여 여행-서비스 사양, 정책 및 조건을 제시한다.

그림 9 의 좌측 중앙에서 플랫폼 관리를 위한 다음의 구성요소는 토큰 관리자 및 지갑의 현금과된 임베디드 구성요소를 포함한다. 나머지 토큰은 템플릿 관리 및 저장, 여행-서비스 알선에 관련된 등급 및 분석 계산에 사용된다. 다음으로, 그림 9의 우측 하단에 있는 알선 관리자는 여행 알선 매칭을 위해 현금화 대상인 지갑과 구성요소를 포함한다. 알선을 위한 나머지 임베디드 구성요소들은 알선의 협상 및 수용 또는 거부에 대한 것이다.

알선을 위해, 전용 구성요소들은 최선의 여행-서비스 제안을 선택하며 실제적인 매칭은 다른 별도의 임베디드 구성요소 내에서 평가된다. 그림 9 의 다섯 번째 하단 좌측 구성요소는 현금화 대상인 임베디드 지갑 구성요소와 알선 실연 관리를 포함한다. 현금화되지 않은 것은 규칙적인 방식으로 구성된 알선 준비와 종료를 위한 구성요소들이다.액터의 추가적인 데이터-오브젝트 교환과 관련하여, 타이토스는 템플릿 사양을

플랫폼-관리자 구성요소에게 제시한다. 또한, 관광객 및 서비스 제공업체는 제안된 알선 정보를 수령한 후에 알선 관리자에게 수락 또는 거절 결정을 통보한다. 마지막으로, 여행자와 서비스 제공업체는 준비 및 실연 관리자 구성요소에게 실연 명령을 전달한다.

나머지 데이터-개체 교환은 그림 9 의 구성요소들 사이에서 발생한다. 이러한 구성요소들은 사용자 온보딩(onboarding) 관리자의 ‘템플릿-작성” 관리자 사용자 프로필을 통해 다음에 설명될 것이다. 템플릿-작성 관리자 구성요소는 플랫폼 관리자로부터 여행-알선 템플릿을 수신하며 두 구성요소들의 각각의 지갑은 TAIC 토큰을 교환한다. 또한, 이전 구성요소는 정책, 사양 및 조건을 알선-관리자 구성요소와 교환한다. TAIC 토큰은 또한 플랫폼의 각 지갑과 알선 관리 간에 교환될 뿐만 아니라 플랫폼과 준비 및 실연 관리자 구성요소의 각각의 지갑 사이에서도 교환된다. 마지막으로, 후자의 구성요소는 해당 알선 관리 구성요소로부터 알선 정보를 수신하며 전자는 평가 및 분석 데이터를 플랫폼 관리자 구성요소로 전송한다.

16

5 블록체인 거래 및 교환 프로토콜

타이토스 시스템의 동적 행동을 설명하기 위해, 우리는 먼저 5.1 절에서 소송의 필요성을 방지하거나 제한하기 위해 관련된 “온 체인(on-chain)” 거래를 제시한다. 5.2 절에서는 “온 체인(on-chain)” 거래 ID 가 삽입되는 여행-서비스 알선을 생성하기 위한 거버넌스 생애주기에 대해 설명한다.

표 1. 소송 방지를 위한 온체인(on-chain) 거래의 집합구성요소 event 설명 이해관계자

타이토스 플랫폼 관리자

1 템플릿 생성 타이토스2 템플릿 업데이트 타이토스3 템플릿 제거 타이토스

사용자 온보딩 관리자4 프로파일 생성 관광객, 서비스 제공업체, 타이토스5 KYC 결과 추가 관광객, 서비스 제공업체, 타이토스

템플릿 작성 관리자

6 역할 추가 관광객, 타이토스7 파트너 추가 서비스 제공업체, 타이토스8 작성된 서비스 유형 템플릿 추가 관광객, 타이토스9 작성된 서비스 제안 템플릿 추가 서비스 제공업체, 타이토스10 선택된 여행-알선 템플릿 관광객, 서비스 제공업체, 타이토스11 정책 정의 관광객, 서비스 제공업체, 타이토스12 사양 정의 관광객, 서비스 제공업체, 타이토스13 협상 가능한 조건 생성 관광객, 서비스 제공업체, 타이토스14 협상 불가능한 조건 생성 관광객, 서비스 제공업체, 타이토스

알선 관리자

15 매칭된 알선 제안 및 요청 추가 타이토스, 관광객, 서비스 제공업체16 사양 병합 타이토스, 관광객, 서비스 제공업체17 환경설정 병합 타이토스, 관광객, 서비스 제공업체18 투표 생성 타이토스, 관광객, 서비스 제공업체19 투표 실행 타이토스, 관광객, 서비스 제공업체20 반대 제안(counteroffer) 추가 타이토스, 관광객, 서비스 제공업체21 최선의 제안 추가 타이토스, 관광객, 서비스 제공업체22 모니터링 가능한 구조 생성 타이토스, 관광객, 서비스 제공업체23 알선 계약 생성 타이토스, 관광객, 서비스 제공업체24 알선 거부 생성 타이토스25 알선 철회(롤백) 추가 타이토스, 관광객, 서비스 제공업체

준비 및 실연 관리자

26 서비스 생성 타이토스, 관광객, 서비스 제공업체27 계약 생성 타이토스, 관광객, 서비스 제공업체28 계약 제거 타이토스29 정책 생성 타이토스, 관광객, 서비스 제공업체30 정책 제거 타이토스31 모니터링 생성 타이토스, 관광객, 서비스 제공업체32 모니터링 제거 타이토스33 TAIC 토큰을 통한 지급 타이토스, 관광객, 서비스 제공업체34 위반 추가 타이토스, 관광객, 서비스 제공업체35 위반 회복 추가 타이토스, 관광객, 서비스 제공업체36 수정 요청 추가 타이토스, 관광객, 서비스 제공업체37 변경 및 수정 추가 타이토스, 관광객, 서비스 제공업체38 롤백(rollback) 추가 타이토스, 관광객, 서비스 제공업체39 역할 제거 타이토스40 파트너 제거 타이토스

175.1 “온 체인(on-chain)” 거래 집합

맨 왼쪽으로, 표 1 의 열은 그림 9 의 아키텍처 모델 구성요소를 나열한다. 모든 아키텍처 구성요소들은 표에 나열된 “온 체인(on-chain)” 거래가 발생한 위치와 함께 나열됨에 유의해야 한다. 이벤트 라벨(event label)이 있는 다음 열은 “온 체인(on-chain)” 거래의 식별 번호로 구성된다. 각 거래의 목적은 “설명 열”에 제시되어 있으며 마지막으로 오른쪽의 열에는 각 거래 당 “관여된 이해 관계자들”의 집합이 나열되어 있다. 이러한 이해 관계자들은 타이토스 플랫폼을 표현한 그림 9 의 액터(actors)에 해당함에 유의해야 한다.

표 1 의 “온 체인(on-chain)” 거래에 관련하여, 준비 및 실연 관리자는 가장 비싼 구성요소이며 그 다음으로 비싼 구성요소는 알선 관리자, 템플릿-모집단 관리자 및 타이토스 플랫폼 관리자 이다. 표 1 의 최소 비용 블록체인 구성요소는 사용자 온보딩(on-boarding) 관리자이다.

5.2 동적 거버넌스

우리는 인용에서 요약된 [38]에 연구를 기반으로 세가지 수명주기를 설명하며 그 중에서 주요한 최상위 생애주기는 그림 10 에 제시되어 있다. 이 수준의 그림은 라벨 협상 및 롤백으로 회색으로 채워진 하위 프로세스 노드에 해당하는 더 낮은 개선 수준을 묘사한다. 따라서, 그림 11 은 개선 협상 생애주기를 보여주며 그림 12 는 개선된 롤백을 보여준다. 마지막으로, 그림 12 는 여행-알선 생성 생애주기의 하위 집합을 그림 9 의 타이토스 아키텍처의 각 액터에 할당한다. 우리는 그림 3(c)에 묘사된 3 개의 부분적인 거버넌스-생애주기 그림에 대하여 제한된 BPMN 표기법을 사용하며 그림 10-12 의 거버넌스 수명주기 내에서 표 1의 이벤트 ID 번호를 빨간색 원(번호 표시됨)으로 추가적으로 사용한다.

6-8

roles, service

9-14

travel arrangement

20

partners,

counteroffer counteroffersubmission

21

22-25

establish

types, network

network population

service offers

disagreenegotiation agreement

arrangement

models

travel arrangement network preparation

End

2-3policy

violation, partner exit, modification

disruptiverollback

rollback

non-disruptive rollback

25

local contracts,

obligations, rights,

policies,

4 5

1terminate

arrangement

r

equest

terminate

enact arrangement a

rrangement

monitorsprepare

arrangement

Start 28 30 32 33 26 27 29 31

그림. 10: 전체 생애주기

18

[38]의 거버넌스 생애주기에서 도출된 것으로서 그림 10 의 타이토스 플랫폼에 대한 구체적인 조정은 여행-알선 네트워크 템플릿의 준비로부터 시작된다. 후자는 작성된 템플릿을 합법적으로 관련성이 있는 소송 계약(고도의 협업 자동화를 달성하기 위해서는 기계 판독 가능)이 되게 하는 모든 요소들에 대한 자리 표시자(place holder)이다. 다음으로, 여행-알선 네트워크 템플릿은 템플릿의 일부인 서비스 유형과 일치하는 서비스 제공자 및 해당 여행-서비스로 채워진다. 원 계약(proto-contract)은 3 가지 가능한 결과로 모든 관련 당사자들에 의해 협상된다. 첫째, 어느 한 당사자가 동의하지 않으면 원계약이 체결되지 못하며 거버넌스 생애주기는 그림 10 에서 종단 노드로 표시된 바와 같이 갑작스런 죽음의 끝에 이른다. 두 번째 결과는 재협상을 고려해야 하는 어느 한 당사자의 반대 제안

(counteroffer)이다. 세 번째 결과는 본 계약 체결에 앞서 원계약에 대한 모든 계약 당사자들 간의 완전한 합의이다.

기존 계약은 각 협업 당사자들에게 사본을 배포함으로써 확립되어야 한다 [28]. 또한, 의무와 권리(즉, 동의어로 “정책”)가 추출된다. 비즈니스 네트워크 모델은 위반이 발생했는지를 관찰하는 비즈니스 네트워크 모델 에이전트에 의해 관찰된다. 기술 알선 준비는 기능적 커뮤니케이션 채널을 통해 기술적 수준에서 서비스를 구축하는 것으로 구성된다. 여행 알선은 이후 협업 당사자들의 투표 결과에 기초하여 다른 롤백(철회) 옵션으로 이어지는 충돌이 발생될 가능성이 있는 때에 차후적으로 실연된다. 투표에서는 정책, 서비스, 협업 당사자의 교환이 충돌의 해소로 이어진다는 점에서 충돌로 인하여 장애가 초래되지 않는다는 결론이 내려진다. 또는, 충돌이 해결될 수 없는 경우에는 전체 계약에 대한 새로운 협상이 요구된다. 마지막으로, 여행-서비스 조항에 대한 비즈니스 사례가 존재하는 경우, 컴퓨팅 성능(연산 능력)을 저하시키는 클라우드 협업 환경에 혼란이 잔존하지 않도록 여행-알선 협업을 질서 정연하게 종료하는 것이 중요하다.

그림 10 의 숫자가 표시된 빨간색 원은 표 1 의 “온-체인(on-chain)” 거래 ID 에 해당하며 거버넌스 생애주기에 할당된다. 따라서, 여행 알선 네트워크를 준비하기 위해, 블록체인에 거래 1, 4 및 5 를 저장하여 템플릿이 생성되고 추가적으로 프로파일이 생성되며 KYC 결과가 사용자 온보딩(onboarding)에 추가된다. 역할, 서비스 유형 및 네트워크 모델을 추가할 때, 해당 사실을 체인 상에서 추가하기 위해 거래 6-8 이 관여된다. 다음으로, 여행-알선 네트워크를 채우려면 완성된 서비스-제안 템플릿 및 선택된 여행-알선 템플릿을 추가하기 위한 거래 9-14 가 요구된다. 또한, 정책과 여행 사양이 정의되며, 최종 “온-체인(on-chain)” 기록은 협상 가능 조건과 협상 불가능한 조건의 생성을 질적으로 포착한다. 반대 제안(counteroffer)가 발급되면 거래 20 이 이러한 사실을 수집하는데, 합의된 협상 계약의 경우 거래 21 이 활성화되며 이견으로 인하여 수명주기가 갑자기 종료되면 거래 2-3 이 템플릿을 업데이트 및 제거한다. “여행-알선”은 기술 서비스 및 지역 계약 생성, 정책 및 네트워크 모니터 추출을 위한 거래 26, 27, 29 및 31 을 관여시킨다. 실연을 위해, 거래 33 은 TAIC 토큰을 통해 여행-서비스 알선에 대한 진행중인 지불을 기록한다. 롤백(철회)에 따라 무중단 결과가 초래되고 다시 여행-알선으로 되돌아가면, 거래 25 는 이러한 롤백 이벤트를 기록한다. 마지막으로, 그림 10 의 생애주기의 정상적인 종료는 계약, 정책 및 모니터링의 제거를 변경 불가한 방식으로 기록하기 위한 거래 28, 30 및 32 를 관여시킨다.

19

그림 10 의 회색으로 채워진 하위 프로세스는 라벨 협상과 함께 그림 11 의 더 낮은 개선 수준으로 묘사된다. 이러한 생애주기는 여행-서비스 제공업체의 협업 커뮤니티를 선택하는 것으로 시작된다. 병렬 분할 후에 어느 한 분기점(branch)에서 원계약이 병합되고 협업 당사자가 추출된다. 병렬 분기의 결합에 이어, 가동 시간(런타임)에 여행-서비스 실연의 목표된 관찰이 가능하도록 모니터링 가능성 구조 [41]가 정의된다. 그런 후, 원계약 계약 제안이 추출되고 투표를 위해 모든 커뮤니티 회원들에게 배포된다. 투표의 결과는 반대 제안을 허용하거나, 롤백이 뒤 따르는 알선을 거부하거나, 제안에 동의하고 계약 체결을 위해 알선을 수락하는 것이다.

pick community

Start

merge 16specifications 17

extractpartners

22

define monitorable constructs

extract eContract proposal

to counter- offer task

to establish arrangement subprocess

to endof lifecycle

permitc

ounteroffer

23accept

arrangement

25rollback

counteroffer

agree on best offer

reject arrangement

21agree

24

disagree

distribute eContract

voting

18 19

그림. 11: 협상 생애주기

표 1 의 “온 체인(on-chain)” 거래에 관련하여, 그림 11 의 계약 사양 병합은 거래 16 및 17 에 의해 뒷받침되며 거래 17 은 기본 설정을 병합한다. 거래 22 는 모니터링 가능성 구조의 생성을 기록하며 후속 거래 18 및 19 는 투표 및 실제 표결의 생성을 기록한다. 투표 결과가 원계약의 거부인 경우 거래 24 와 거래 25는 거절 알선과 후속 롤백(철회)의 생성을 저장한다. 마지막으로 거래 21 과 23 은 최선의 알선 제안을 추가하고 여행-알선 계약의 생성을 각각 기록한다.

20to establish arrangement subprocess

22

23update

non-disruptive36 37

monitorable38 constructs

policy

updatearrangement

modification performmodifications

modifications

modifications

Start

extractreason

violation

disruptive modification

34 study policy35 violation

voluntary partner exit

forced partner

exit

38

to negotiation

requestnegotiation

populate service offers

add new partner

remove partner

subprocess 9 7 40

그림 12: 롤백(철회) 생애주기

그림 12 의 두 번째 개선 생애주기에서는 그림 10 의 롤백(철회) 하위 프로세스에 대한 옵션을 보여준다. 롤백 생애주기는 “롤백 에스컬레이션(단계적 확대)”에 대한 이유를 추출하는 것으로 시작된다. 우리는 병렬 분기의 포괄적인 분할(사용 가능한 경로 중 몇 가지를 선택할 수 있음을 의미)로 이어지는 “정책(즉, 동의어로 의무) 위반”이 발생한다고 가정한다. 하나의 옵션은 정책 위반을 연구한 다음에 정책 수정 및 파트너 제거로 이어지는 또 다른 포괄적인 분할을 실행하는 것이다. 그림 12 의 맨 위 분기에서, 수정 사항은 여행 알선 및 모니터링 가능성 구조의 업데이트 시에 정점에 이르렀다가 최고 수준의 생애주기(그림 10)로 되돌아간다. 그림 12 의 하단에서, 자발적 중도 탈퇴로 인해 파트너가 즉시 제거되거나 정책 위반에 관한 연구에 대한 대응은 파트너가 제거로 이어진다. 차후적으로, 여행 알선을 유지하고 서비스 제안을 채우고 새로운 협상을 요청하기 위해 새로운 파트너가 추가된다. 후자의 공정 단계는 기존의 여행 알선을 더 이상 유지할 수 없을 정도로 지장을 초래하는 여행 알선 수정이 있은 후에 바로 활용 가능하다.표 1 의 “온 체인(on-chain)” 거래에 관련하여, 그림 12 의 롤백 생애주기는 정책 위반에 대한 연구 결과로부터 발생된 위반 및 해당 복구를 저장하기 위해 거래 34 및 35 를 사용한다. 거래 36 및 37 은 변경 세부사항과 함께 “온 체인(on-chain)” 변경 요청을 추가한다. 다음으로, 거래 23 및 22 는 롤백 생애주기가 그림 10 의 더 높은 전체 생애주기에서 종료되기 전에 “새로운 여행-알선 계약” 및 “관련성이 있는 모니터링 가능성 구성”을 저장한다. 그림 12 의 하단에 있는 대체 경로의 경우, 거래 40 은 여행-알선 파트너 제거를 기록한다. 거래 7 와 9 는 새로운 파트너 및 작성된 “서비스-제안 템플릿”의 추가를 각각 기록한다. 마지막으로, 거래 38 은 롤백의 세부사항을 체인 상에 저장한다.

s s oait T

er idvo r Pe ic vSe

t isruo T

Serv

ice

Prov

ider

Taito

ssTo

uris

t

21

modify arrangement

templatesdisruptive

non-disruptive rollback

Start

travel a

rrangement network

preparation

populateroles

roles,

negotiation (vote/

counteroffer)

modified Offer/

acceptarrangement

enacta

rrangement

terminatearrangement End

travel

service request

eContract

vote

Start

arrangement

network preparation

populate

roles

matchOffers negotiation

eContract

establisha

rrangement

preparearrangement m

onitorterminate

End

Start

travel arrangement

network preparation

partners,service offers

populate servicetype templates

modified offer/vote

negotiation (vote/

counteroffer)

modify service offer

templates

acceptarrangement

non-disruptive

disruptive

enacta

rrangement

rollback

terminatearrangement End

그림 13: 이행관계자들의 생애주기

그림 13 에 묘사된 타이토스 플랫폼의 이해 관계자에게 특정적인 생애주기 과제가 할당된다. 이러한 생애주기는 관광객, 타이토스 및 여행-알선 서비스 제공업체를 위해 소위 BPMN 풀(pool)을 각각 보여준다. 3 개의 모든 이해 관계자들은 여행-알선 네트워크 준비에 관여하면서 생애주기를 시작한다. 이후, 포함된 역할은 전체적인 여행-서비스 알선의 소비자인 관광객과 서비스 제공자인 타이토스에 의해 수행된다. 서비스 공급업체는 구체적인 서비스 제안 및 해당 서비스 유형의 관련 역할로 서비스 유형을 채운다. 2.2 절에서 설명된 것처럼 협업 모델은 일련의 서비스 공급업체로 확장됨에 유의해야 한다. 차후적으로, 모든 이해 관계자들은 관광객 또는 서비스 제공업체가 수정할 수 있는 원계약을 협상한다. 모든 이해 관계자들이 여행 알선에 동의하면, 타이토스 플랫폼이 실화 단계에 대하여 요구되는 모든 프로세스를 준비하는 계약이 체결된다. 실연 중에 충돌이 발생하면 관광객 및 서비스 제공업체를 관여시키는 롤백은 이전에 논의된 지장적(disruptive)이거나 지장적이지 않은(non-disruptive) 결과를 초래할 수 있다. 후자의 시나리오에서, 타이토스는 모니터링 가능성 구조의 재배치를 가능하게 한다. 마지막으로, 그림 13 에서 모든 이해관계자들은 소비 후에 컴퓨팅 파워(연산 능력) 손상을 초래할 정도로 혼란이 축적되지 않게 하는 목적으로 여행-서비스 알선을 종료한다.

22

6 타당성 평가

이 절에서, 우리는 앞서 4절에서 설명된 타이토스 플랫폼 아키텍처의 신속한 시스템 전개에 필요한 기존 기술 및 신기술의 가용성을 평가하기 위해 종이 기반의 방식을 채택한다. 이러한 기술 스택(technology stack)은 타이토스 플랫폼의 특정 요구사항을 충족시키는 데에 유용한 블록체인 제품, 프로젝트 및 연구 이니셔티브로 구성된다. 시스템의 신속한 전개를 위한 제안은 잠정적인 것임에 유의해야 한다.

나머지 구조는 다음과 같다: 6.1 절은 인공 지능과 블록체인이 상호 보완 가능한 방법을 제시하고 타이토스 플랫폼의 맥락에서 인간 사용자를 지원하기 위해 인공 소프트웨어 에이전트를 사용하는 방법에 대하여 설명한다. 다음 6.2절에서는 블록체인에 대한 데이터 관리 옵션에 집중한다. 6.3절은 타이토스 플랫폼의 안전한 운영을 위한 이해 관계자들의 인증에 관련하여 해당 연구물 및 업계 관행을 제시한다. 마지막으로, 6.4절에서는 스마트 계약 플랫폼에 대한 논의와 함께 스마트 계약 플랫폼의 검증 가능성을 논의한다.

6.1 인공 지능 및 소프트웨어 에이전트

인공 지능(AI)은 타이토스 플랫폼, 특히 소프트웨어 에이전트에 의해 활용되어 자동화 및 편의성 등과 같이 3절에서 언급된 품질 목표 중 일부를 달성 할 수 있다.SingularityNET1 은 암호 해독 또는 인공 지능 서비스와 교환하여 인공 지능 소프트웨어를 구매 및 판매하고자 하는 사람들을 위해 블록체인 기반의 시장을 제공한다. SingalarityNET 의 스마트 계약 기반 인공 지능 서비스는 요구되는 인공지능(AI) 기능을 통해 타이토스를 시동(부트스트랩(bootstrap)) 하기에 이상적인 출발점이 될 수 있다. DeepBrain-Chain2는 블록체인 기술을 사용하여 분산형, 저비용 및 개인정보 보호 AI 컴퓨팅 플랫폼을 개발한다. DeepBrain-Chain2 는 본질적으로 전 세계적으로 수많은 많은 노드가 인공지능(AI) 기업들에게 연산 능력을 제공하고 보상으로서 디지털 동전을 받을 수 있는 분산형 신경망 이다. 타이토스 플랫폼은 계산 집약적 인공지능(AI) 서비스를 위하여 이러한 인프라를 활용할 수 있다.Namahe3는 윤리적 비즈니스 활동을 지원하기 위해 블록체인 기반의 엔드-투-엔드(end-to-end) 공급망 플랫폼을 구축하고 있다. 이것은 AI 의 사용을 통해 소프트웨어 및 물류 자동화를 향상시켜 시스템이 수요 변화 또는 지연 등 외부 사건에 대응할 수 있는 속도를 높인다. 이러한 기능들 중 일부는 타이토스 플랫폼의 맥락에서 유용 할 수 있다. 그러나 이러한 모든 기술은 아직 초기 단계에 있다는 사실에 유의해야 한다.

1 https://singularitynet.io/2 https://deepbrainchain.org/3 https://namahe.io/

23인공지능(AI) 블랙 박스는 설명력 문제로 어려움을 겪는다. 많은 사람들은 그러한 인공지능(AI) 시스템을 전적으로 신뢰하는 것을 경계한다. 그러나 타이토스의 경우처럼 블록체인을 인공지능(AI)를 함께 사용하면 의사결정 프로세스를 추적 할 수 있는 경로를 제공하는 명확한 감사 추적 기능을 용이하게 사용할 수 있다. 이것은 소송 목적, 결정 검토 및 시스템 안정성 향상에 유용하다. 그림 6, 7 및 8 은 플랫폼의 사용을 용이하게 하고 인간 사용자를 지원하는 인공 소프트웨어 에이전트의 필요성을 보여준다.인공 에이전트는 순전히 소프트웨어 기반이거나 하드웨어와 임베디드 소프트웨어의 조합 일 수 있다 [56]. 양자의 경우, 인공 에이전트는 일련의 센서, 내부 지식 기반, 컨트롤러 및 액추에이터(actuator)로 구성된다. 센서는 복잡한 정보 구조를 저장하기 위해 지식 기반이 사용되는 동안 상황별 이벤트를 인식하는 데에 사용된다. 컨트롤러는 지식 기반에 저장된 데이터뿐만 아니라 감지된 데이터를 사용하여 알고리즘 추론 기반 입력을 액츄에이터에 제공한다. 이러한 전용 에이전트 유형은 특정 작업을 수행하기 위해 생성되므로 에이전트의 생애주기는 할당된 작업이 성공적으로 완료되거나 취소될 때에 종료될 것으로 예상된다. JADE 플랫폼[7, 8]은 다중 에이전트 시스템의 구현을 단순화시키는 잘 정립된 소프트웨어 틀(framework)이다.

6.2 데이터 관리

타이토스 플랫폼은 그림 10 에 묘사된 생애주기 동안 데이터가 한 구성요소에서 다른 구성요소로 전달 될 때 관광-서비스를 지원하기 위해 저장, 업데이트, 질의 및 처리되어야 할 많은 양의 데이터를 처리해야 한다. 그러므로 중앙적 권한을 필요로 하지 않는 도구로서 데이터 불변성, 높은 처리량, 낮은 대기 시간, 풍부한 권한 부여 및 쿼리 기능을 지원할 수 있는 도구를 활용하는 것이 필수적이다. 데이터 불변성 및 분산형 스토리지(storage)와 같은 기능은 블록체인 플랫폼에서 제공될 수 있지만 각 블록의 크기 제한으로 인해 모든 관련 데이터를 트랜잭션으로 저장하는 것은 불가능하다. Inter Planetary File System4(인터플래닛터리 파일 시스템 4)(IPFS) [9]는 블록체인 기반의 타이토스 플랫폼을 보완할 수 있는 기존의 적절한 시스템이다. IPFS 는 분산형 블록 스토리지 모델을 제공하는 고성능, 개방형 소스, ‘피어 투 피어(peer-to-peer(P2P))’ 하이퍼 미디어 프로토콜(hypermedia protocol)이다. IPFS 로 많은 양의 데이터를 처리할 수 있으며 변경 불가능한 영구 링크를 블록체인 트랜잭션에 추가 할 수 있다. 따라서, 타임 스탬프(time-stamped)된 보안 콘텐트를 보존하는 동안 전체 데이터 저장을 피할 수 있다.

IPFS 는 확장 가능한 분산형 스토리지를 구현하는 데 사용할 수 있지만, BigchainDB[34]는 대규모 데이터 세트(dataset)에서 복잡한 작업을 실행하는 데에 적합한 보완적인 시스템이다. BigchainDB 는 높은 처리량, 낮은 대기 시간, 분산형 제어, 변경 불가능한 데이터 스토리지를 구현할 수 있으며 강력한 쿼리 기능을 제공한다. BigchainDB 는 중앙 집중 데이터베이스 또는 분산형 데이터베이스(예: IPFS)와 함께 사용될 수 있으며 Ethereum 및 Qtum 과 같은 다른 분산형 블록체인 시스템과 통합될 수 있다

4 https://ipfs.io/

24

6.3 인증 및 키 관리

타이토스 플랫폼의 경우, 식별 키를 안전하게 저장하고 참여하는 이해 관계자의 인증된 ID 를 명확히 하는 것이 중요하다. ZeroPass5는 전체 ‘개인 키’가 ZeroPass 서버에 저장되지 않는 블록체인 서비스이다. 대신, ZeroPass 는 식별 키를 분할하는데, 절반은 암호로 보호되는 반면에 나머지 절반만 사용자에게 공개된다. 사용자는 부여된 접근 권한을 통해 제 3 자와 키의 절반을 공유 할 수 있다. 여러 사용자가 블록체인에 대한 브로드캐스팅(broadcasting)보다 먼저 트랜잭션에 서명하는 다중 서명은 키 분할에 대한 대체 수단으로 사용될 수 있다. 많은 지갑 6은 이미 다중 서명 메커니즘을 제공한다. 타이토스 플랫폼에 키의 절반을 저장하지 않고, 이해 관계자는 타이토스 플랫폼에 두 번째 개인 키를 생성하여 저장한다. 그러므로 유효한 거래에서는 타이토스 플랫폼과 이해 관계자의 다중 서명이 동시에 요구된다. 강화된 보안 수단은 개인 키를 저장하기 위해 여러 개의 서버를 사용하는 방안을 포함한다[25]. 그러나 결과적으로 대기 시간 증가 및 충돌 등 협업 비용이 발생될 수 있다. 명확하게 정의된 규칙(오직 두 개의 서버 만이 트랜잭션에 서명하는 것으로 충분)은 그러한 문제를 완화하는 데 도움이 될 수 있다. 인증에 관련하여, Authcoin 프레임워크[29, 30]는 도전 응답 프로토콜(challenge response protocol)을 사용하여 개인의 신원을 인증하는 유연한 수단을 제공하도록 설계된 것으로서 최근 등장했다.

6.4 스마트 계약 플랫폼 및 검증 가능성

그림 2 의 하단에 표시된 것처럼 스마트 계약은 고도로 자동화된 타이토스 플랫폼의 기본 요소이다. 이 플랫폼은 그림 9 에 제시된 아키텍처를 구현하기 위해 상당량의 스마트 계약의 전개를 요구한다. 이더리움(Ethereum)은 당연히 타이토스 플랫폼의 잠재적인 후보이다. 이것은 현재 “온-체인(on-chain)” 합의의 확립을 요구하는 “매우 중요하고 가치 있는 거래”에 적합한 “작업 증명(PoW)” 기반의 합의 메커니즘을 사용하고 있다. 그러나 이것이 표 1 에 설명된 관련 협업 이벤트뿐만 아니라 모든 중요한 소송을 변경 불가한 방식으로 저장하는 데에 사용되는 경우, 처리량이 낮아지고 대기 시간이 길어지고 트랜잭션 검증 비용이 높아질 수 있다.

최근, 채굴자(miner)가 보유한 토큰의 비율에 따라 채굴 권한을 부여하는 작업 증명(PoS) 기반의 스마트 계약 플랫폼이 등장했다. Qtum7은 주목할만한 예이다. 이더리움(Ethereum)과 비슷하게 퀀텀(Qtum)은 솔리디티(Solidity)를 스마트 계약 개발 언어로 사용하므로 경험이 있는 솔리디티(Solidity) 개발자들은 퀀텀(Qtum)을 용이하게 사용할 수 있다. 정확한 일자는 알 수 없지만, 이더리움(Ethereum) PoS 로 전환할 것으로 예상된다.

5 https://www.zeropass.io/6 https://bravenewcoin.com/news/the-best-multisignature-wallets-for-2016/7 https://qtum.org/ens

25블록체인 대신에 DAG(방향성 비순환 그래프)를 사용하는 IOTA8 은 이더리움

(Ethereum)과 퀀텀(Qtum)에 대한 대안이다. IOTA 는 크기에 관계없이 “확장성이 매우 크고 동시에 발생하는 트랜잭션”을 신속한 확인을 통해 처리하도록 설계되었다. 그러나 IOTA 는 투표(voting)와 같이 거래 주문을 요구하지 않는 스마트 계약 만을 지원한다.

Hyperledger(하이퍼레저)[61]는 이더리움(Ethereum)과 퀀텀(Qtum)에 대하여 허가된 대안이다. Hyperledger 는 스마트 계약을 위한 모듈식 구현을 제공한다 [13]. Hedera-Hashgraph(헤데라 해시그래프)9 와 Stellar(스텔라)10는 합의를 달성하기 위해 BFT(비잔티움 장애 허용) 메커니즘을 사용하는 대안적인 플랫폼이다.

예를 들어, 스텔라(Stellar)는 일련의 유효성 검사기(validators)가 공존 할 수 있도록 하는 연합형 비잔틴 합의을 사용한다. 이러한 세트(set)는 모든 노드가 법률적 및 성능적 측면을 고려함으로써 분산형 방식으로 결정될 수 있다. 이더리움(Ethereum)에 비해 거래 비용이 적고 검증 시간이 약 3~5 초[55] 소요되며 거래 처리량이 매우 높다 [11].

스마트 계약은 많은 수의 가상 토큰을 처리 할 것으로 예상되므로, 거래 상대방을 끌어 들이기에 충분할 만큼 재정적인 인센티브를 용이하게 높일 수 있다[2]. 또한, 중앙 집중형 클라우드 서비스 및 기존 분산형 애플리케이션 플랫폼과 달리, 스마트 계약 플랫폼은 임의의 참가자를 감안하므로 공략 가능한 영역을 확장한다. 그러므로, 실연(enactment) 전에 이러한 스마트 계약의 건전성을 점검하고 동시성 충돌 또는 의존성 문제를 제거하는 것이 중요하다[3]. 스마트 계약의 검증 가능성은 법률 준수가 입증되어야 하는 경우에 특히 중요하다.

Securify(시큐리파이)11은 최근 중요한 보안 문제[60]를 탐지하기 위해 Solidity(솔리디티) 스마트 계약에 대한 정식적인 검증을 지원할 수 있는 온라인 서비스 풀버전(full version)을 출시했다. 준수 및 위반 패턴은 에테르 유동성(ether liquidity), 호출 후 기록 없음(no writes after call), 쓰기 제한, 전송 제한, 예외사항의 처리, 거래 정렬 종속성(ordering dependency) 및 검증된 주장 등의 보안 속성에 대하여 정의된다. Securify(시큐리파이)는 장래성이 좋은 것으로 보이지만 여전히 초기 단계에 있다. Why(와이)3 [22]는 이제 Solidity(솔리디티) 웹 IDE[1]에서 사용할 수 있는 실험적인 정식 검증 백엔드(backend) 이다. Embark-framework(임바크-프레임워크)12 및 Populus(포풀루스)13 는 스마트 계약의 개발, 전개 및 정식적인 검증을 지원하는 도구이지만 아직 초기 단계에 있다.

또한, 스마트 계약의 검증은 여러 학술지에서 논의된다. _____[16]에서, 연구자들은 스마트 계약을 개발하고 학생들이 일반적으로 저지른 몇 가지 실수의 유형을 확인하면서 학생들을 관찰했다.

8 https://iota.org/9 https://www.hedera.com/

10 https://www.stellar.org/11 https://securify.ch/12 https://github.com/iurimatias/embark-framework13 http://populus.readthedocs.io/en/latest/

26

관찰된 버그(bug) 와 함정은 상태 기계(state machine) 를 암호화 할 때 발생되는 오류 및 암호 사용에 실패한 경우 등 스마트 계약 프로그램의 고유한 특성으로

인하여 발생된다. 또한, 콜스택(call-stack), 블럭해시(blockhash) 및 인센티브버그 등 Solidity(솔리디티) 특정적인 실수도 관찰되었다. 이러한 관찰을 토대로,

연구자들은 일반적인 개발 실수를 줄이기 위해 최선의 휴리스틱스( 경험적 접근법) 를 제시한다. 경험적 연구들은 이러한 휴리스틱스( 경험적 접근법) 를 적용할 때

스마트 계약 코드에서 보안 문제가 상당히감소함을 보여준다. _____[33] 의 저자는 EVM 바이트 코드(bytecode) 프로그램의 결함을 검출하기

위해 기호실행(symbolic-execution) 의 사용에 대하여 논의한다. _____ [10]의 저자는 프로그램과 익명의 사용자가 제 3 “자 프로그램의 공개 방법을 호출 할 때 ” “ 신뢰할 수 있는 프로그램 과 신뢰할 수 없는 프로그램" 을 조합하면 보안이

취약해진다고 주장한다. 그 저자들은 스마트 계약의 기능적 정확성과 런타임(실행 시간) 안전성을 분석 및 검증하기 위해 F* 라고 명명되는 함수형 프로그래밍언어의

사용을 제안한다.최근, Solidty(솔리디티) 를 기반으로 하는 스마트 계약의 대안으로서 정식적인

검증을 지원하기 위해 기초부터 설계된 플랫폼이 등장했다. 예를 들어, Cardano(카르다노)14 는 기능적인 Haskell(하스켈) [59] 을 사용하며 Aeternity(애터니티)15 는 Erlang(에어랑) [32] 을 사용한다. Haskell(하스켈) 과 Erlang(에어랑) 은 모두

정식적인 검증을 위해 자세히연구되어왔다[31] [23]. 입증 가능하게 올바른 보안 모델을 사용하여 프로토콜을 개발할 때 기대할 수

있는 상당한 장점은 상대방이 그러한 프로토콜을 위반하는 것이 불가능하다는 것이다. “ 그러나 실제 코드 행(line)” “ ” 과 검증에 요구되는 행 간의 트레이드오프(tradeoff) 가 달성되어야 한다 16. NEO17 의 경우처럼 Java 등 고급 프로그래밍

언어가 사용될 때 기존의 검증도구[14] 가활용될 수 있다.

7 결론

본 백서에서는 명목 화폐 간의 환율 손실, 여행 서비스 제공업체들 간의 데이터 표준 편차, 여행 서비스에 사용되는 이기종 기술, 기존 정보 비대칭 등은 업계의 기존 문제를 다루는 블록체인 기반 여행 주선 플랫폼을 제시한다. 본 백서는 기존

네트워크 모델에 포함된 서비스 유형과 임의의 여행- 서비스 제안을 매칭할 수 있는 특정적인 조직 간 협업 모델을 제안한다. 구체적으로, 이러한 건실한 모델을 “ ” 기반으로 이해관계자들이 할당된 여행 특정적 자동화 플랫폼 에 대한 요구 사항을

탐구한다. 이러한 요구사항 집합을 기반으로 플랫폼 아키텍처는 구성요소 및 해당 “구성요소와 이해관계자들 간의 데이터- ” 객체 교환으로 구성된다. 다음으로, 본

백서는 충돌이 발생할 경우 잠재적으로 소송에 관련된 이벤트를 변경 불가능한 “방식으로 저장하기 위해 온-체인(on-chain)” “거래가 매핑되는 여행- ” 주선 구성의

확립을 위한 거버넌스 생애주기를 제시한다. 마지막으로, 신속한 전개에 관련된 타당성 연구는 타이토스 플랫폼의 모든구성요소를 다루는주요한 블록체인 측면과

함께기존 기술 스택(technology stack) 을 제시한다.14 https://www.cardano.org/en/home/15 https://

aeternity.com/16 https://whycardano.com/science-and-engineering/#formal-specification-and-

verification17 https://neo.org/

27

연구 질문에 답하기 위해, “타이토스 플랫폼에 대한 목표- ” 모델 의 주요 가치 명제는 플랫폼 관리, 온보딩(onboarding) 사용자, “여행- ” 주선 템플릿 작성, 그러한 주선의 생성, 실연 및 준비 등에 대하여 5 개의 주요 개선 분기(branches)로

“구분되는 관광- ” 서비스 주선 플랫폼을 제공하는 것이다. 이러한 기능적 목표 외에도, “일련의 품질 목표는 목표- ” 모델 내에서 적절한 위치로 할당 및 밀착되어 애플리케이션- 시스템을 구현한다. “이해관계자들의 역할에 관련하여 목표- ”모델 은

타이토스 자체를 고려하며 관광객 및 여행 주선을 위한 서비스 제공업체를 추가적으로 감안한다. 마지막으로, “목표- ” 모델 은 타이토스 플랫폼의 어떤 기능이

TAI 및 TAIC 토큰으로 현금화를 요구하는지에 대한 추론을 감안한다. 타이토스 플랫폼의 아키텍처는 특정 휴리스틱( 경험론적 접근법) 맵핑에 기반한

“목표- ” 모델 로부터 도출되는 것으로서 그에 상응하여 기능 목표의 두 번째 수준의 개선에 해당하는 하위 구성요소가 포함된 5 개의 최상위 구성요소가 있다. 회색

음영 처리된 구성요소는 TAI 및 TAIC 토큰에 의해 현금화되는 반면에 구성요소 도식 내의 액터(actors) 는 목표 도식의 역할 집합에 해당한다. “ ” 추가된 내용 대비

“ ” 목표 도식 은 아키텍처 토폴로지가 구성요소들 간 데이터 개체의 교환으로 구성된다는 것이다. 또한 액터(actors) 와 구성요소들간의 데이터 교환은 구현 시에

애플리케이션 프로그래밍인터페이스를 통해 이루어지며 개념적으로묘사되었다. 타이토스 아키텍처에서 가능한 구성요소들과 이해관계자들 간의 동적 교환

프로토콜에 관련하여, 우리는 잠재적으로 소송에 관련이 있는 일련의 온-체인(on-chain) 거래를 구체적으로 제시한다. “여행- ” 서비스 주선의 준비 및 실연을 위한

구성요소는 온- 체인 거래 금액이 최대인 가장 값비싼( 그 다음으로는 주선 관리, 템플릿 작성 관리, 타이토스 플랫폼 관리, 사용자 온보딩 관리에 대한 구성요소)

블록체인 구성요소이다. 각 온- 체인 거래는 선행 연구 출판물에서 도출된 적응형 거버넌스 생애주기 안으로 배치된다. 이러한 생애주기는 모집단, 협상, 롤아웃(

공개), 실연, 정연한 종료를 위한 롤백(철회) “을 통해 네트워크- ” 템플릿 작성에 대한 완전한 관리로 구성된다.

마지막으로 우리는 스택(stack) 을 형성하는 기존 기술을 통해 타이토스 플랫폼을 신속하게 전개하는 것에 대하여 연구한다. 후자는 타이토스-아키텍처

구성요소의 애플리케이션- 시스템 구현을 실현하는 대규모 인공- 기술 및 블록체인 기술로 구성된다. 확장성 및 성능이낮은 수준이고 도구 지원을 통한 스마트 계약의

건실성을 검증 할 수 있는 능력이 불충분한 이더리움(Ethereum) 스마트 계약 플랫폼의 초기 약점과 결함은 다양한 고성능 블록체인 솔루션의 등장으로 극복

가능해졌다. “현재 쟁점들 중의 하나는 여행- ” 서비스 주선에 대한 관리 시에 의사결정 및

추천 지원을 위해 스마트 계약 층의 맨 위에 있는 다중 에이전트 시스템 층을 통해 인공 지능의 통합을 가장 효과적인방식으로 달성하는 것에 관련한다.

28

References

1. Ethereum. Solidity-browser. https://ethereum.github.io/browser-solidity, 2018.2. N. Alchemy. A short history of smart contract hacks

on Ethereum. URL: https://medium.com/new-alchemy/ a-short-history-of-smart-contract-hacks-on-ethereum-1a30020b5fd,2018. (Accessed September 29, 2018).

3. A. Avizienis, J. Laprie, B. Randell, and C. Landwehr. Basic concepts and taxonomy of dependable and secure computing. IEEE transactions on dependable and secure computing, 1(1):11–33, 2004.

4. K. Balasubramanian, A. Gokhale, G. Karsai, J. Sztipanovits, and S. Neema. Devel-oping applications using model-driven design environments. Computer, 39(2):33–40, 2006.

5. E. Becker. Overbooked: the exploding business of travel and tourism. Simon andSchuster, 2016.

6. D. Bell. Uml basics: The component diagram. IBM Global Services, 2004.7. F. Bellifemine, A. Poggi, and G. Rimassa. Jade–a fipa-compliant agent framework.

In Proceedings of PAAM, volume 99, page 33. London, 1999.

8. F. Bellifemine, A. Poggi, and G. Rimassa. Jade: a fipa2000 compliant agent development environment. In Proceedings of the fifth international conference on Autonomous agents, pages 216–217. ACM, 2001.

9. J. Benet. Ipfs-content addressed, versioned, p2p file system. arXiv preprintarXiv:1407.3561, 2014.

10. K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi, G. Gonthier,N. Kobeissi, A. Rastogi, T. Sibut-Pinote, N. Swamy, and S. Zanella-Beguelin. Formal verification of smart contracts. In Proceedings of the 2016 ACM Workshop on Programming Languages and Analysis for Security-PLAS’16, pages 91–96, 2016.

11. Brian Patrick Eha. How Barclays Aims to Bring a Billion Un-banked into the Fold. URL: https://www.americanbanker.com/news/ how-barclays-aims-to-bring-a-billion-unbanked-into-the-fold, 2016. (Ac-cessed September 29, 2018).

12. V. Buterin et al. A Next-Generation Smart Contract and Decentralized Application Platform - Whitepaper. URL: http://blockchainlab.com/pdf/Ethereum_white_ paper-a_next_generation_smart_contract_and_decentralized_application_ platform-vitalik-buterin.pdf, 2014. (Accessed September 29, 2018).

13. C. Cachin. Architecture of the hyperledger blockchain fabric. In Workshop onDistributed Cryptocurrencies and Consensus Ledgers, 2016.

14. J. Chimento, W. Ahrendt, G. Pace, and G. Schneider. S ta rvoo r s: a tool for combined static and runtime verification of java. In Runtime Verification, pages 297–305. Springer, 2015.

15. M. Crosby, P. Pattanayak, S. Verma, and V. Kalyanaraman. Blockchain technology:Beyond bitcoin. Applied Innovation, 2:6–10, 2016.

16. K. Delmolino, M. Arnett, A. Kosba, A. Miller, and E. Shi. Step by Step Towards Creating a Safe Smart Contract: Lessons and Insights from a Cryptocurrency Lab, pages 79–94. Springer Berlin Heidelberg, Berlin, Heidelberg, 2016.

17. T. Dogru, M. Mody, and C. Leonardi. Blockchain technology & its implications forthe hospitality industry. 2018.

18. R. Eshuis, A. Norta, O. Kopp, and E. Pitkanen. Service outsourcing with process views. IEEE Transactions on Services Computing, 2014. In press. Preprint at http://is.ieis.tue.nl/staff/heshuis/TSC2014.pdf.

29

19. R. Eshuis, A. Norta, and R. Roulaux. Evolving process views. Information and Software Technology, 80:20–35, 2016.

20. R. Eshuis, A. Norta, and R. Roulaux. Evolving process views. Information and Software Technology, 80:20 – 35, 2016.

21. R. S. et al. Unified Modelling Language. http://www.uml.org, 2004.22. J.-C. Filliˆatre and A. Paskevich. Why3 – Where Programs Meet Provers. In

ESOP’13 22nd European Symposium on Programming, volume 7792 of LNCS, Rome, Italy, Mar. 2013. Springer.

23. L. Fredlund, D. Gurov, T. Noll, M. Dam, T. Arts, and G. Chugunov. A verification tool for erlang. International Journal on Software Tools for Technology Transfer, 4(4):405–420, 2003.

24. I. Goodfellow, Y. Bengio, A. Courville, and Y. Bengio. Deep learning, volume 1.MIT press Cambridge, 2016.

25. A. Hari and T. Lakshman. The internet blockchain: A distributed, tamper-resistant transaction framework for the internet. In Proceedings of the 15th ACM Workshop on Hot Topics in Networks, HotNets ’16, pages 204–210, New York, NY, USA, 2016. ACM.

26. S. Ivanov, C. Webster, and K. Berezina. Adoption of robots and service automation by tourism and hospitality companies. 2017.

27. A. Kumar, O. Irsoy, P. Ondruska, M. Iyyer, J. Bradbury, I. Gulrajani, V. Zhong,R. Paulus, and R. Socher. Ask me anything: Dynamic memory networks for natural language processing. In International Conference on Machine Learning, pages 1378–1387, 2016.

28. L. Kutvonen, A. Norta, and S. Ruohomaa. Inter-enterprise business transaction management in open service ecosystems. In Enterprise Distributed Object Computing Conference (EDOC), 2012 IEEE 16th International, pages 31–40. IEEE, 2012.

29. B. Leiding, C. H. Cap, T. Mundt, and S. Rashidibajgan. Authcoin: Validation and Authentication in Decentralized Networks. In The 10th Mediterranean Conference on Information Systems - MCIS 2016, Cyprus, CY, September 2016.

30. B. Leiding and A. Norta. Mapping requirements specifications into a formalized blockchain-enabled authentication protocol for secured personal identity assurance. In International Conference on Future Data and Security Engineering, pages 181–196. Springer, 2017.

31. M. Leucker, T. Noll, P. Stevens, and M. Weber. Functional programming languages for verification tools: a comparison of standard ml and haskell. International Journal on Software Tools for Technology Transfer, 7(2):184–194, 2005.

32. M. Logan, E. Merritt, and R. Carlsson. Erlang and OTP in Action. Manning Publications Co., 2010.

33. L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor. Making smart contracts smarter. Cryptology ePrint Archive, Report 2016/633, 2016.

34. T. McConaghy, R. Marques, A. Mu¨ller, D. De Jonghe, T. McConaghy, G. McMullen,R. Henderson, S. Bellemare, and A. Granzotto. Bigchaindb: a scalable blockchain database. white paper, BigChainDB, 2016.

35. S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.36. N. Narendra, A. Norta, M. Mahunnah, L. Ma, and F. Maggi. Sound conflict

management and resolution for virtual-enterprise collaborations. Service Oriented Computing and Applications, 10(3):233–251, 2016.

37. B. Neuhofer, D. Buhalis, and A. Ladkin. A typology of technology-enhanced tourism experiences. International Journal of Tourism Research, 16(4):340–350, 2014.

30

38. A. Norta. Designing a smart-contract application layer for transacting decentralized autonomous organizations. In International Conference on Advances in Computing and Data Sciences, pages 595–604. Springer, 2016.

39. A. Norta and R. Eshuis. Specification and verification of harmonized business- process collaborations. Information Systems Frontiers, 12(4):457–479, 2010.

40. A. Norta and R. Eshuis. Specification and verification of harmonized business- process collaborations. Information Systems Frontiers, 12:457–479, 2010. 10.1007/s10796-009-9164-1.

41. A. Norta and P. Grefen. Discovering patterns for inter-organizational business collaboration. International Journal of Cooperative Information Systems (IJCIS), 16:507 – 544, 2007.

42. A. Norta, P. Grefen, and N. Narendra. A reference architecture for managing dynamic inter-organizational business processes. Data & Knowledge Engineering, 91(0):52 – 89, 2014.

43. A. Norta and L. Kutvonen. A cloud hub for brokering business processes as a service: A rendezvous platform that supports semi-automated background checked partner discovery for cross-enterprise collaboration. In IEEE SRII Global Conference (SRII), 2012 Annual, pages 293–302, 2012.

44. A. Norta, L. Ma, Y. Duan, A. Rull, and K. K˜olvart, M.and Taveter. econtractual choreography-language properties towards cross-organizational business collabora- tion. Journal of Internet Services and Applications, 6(1):8, 2015.

45. A. Norta, A. Vedeshin, H. Rand, S. Tobies, A. Rull, M. Poola, and T. Rull. Self- aware agent-supported contract management on blockchains for legal accountability. URL: http://whitepaper. agrello. org/Agrello Self-Aware Whitepaper. pdf, 2017.

46. Object Management Group. Business Process Modeling Notation (BPMN), Version2.0. URL: http://www.bpmn.org/spec/BPMN/2.0/, 2011. (Accessed September 29,2018).

47. I. O¨ nder and H. Treiblmaier. Blockchain and tourism: Three research propositions.Annals of Tourism Research, 2018.

48. B. Panikkar, S. Nair, P. Brody, and V. Pureswaran. ADEPT: An IoT Practitioner Perspective, 2014.

49. M. Pilkington. Can blockchain technology help promote new tourism destinations? the example of medical tourism in moldova. 2017.

50. M. Pilkington, R. Crudu, and L. Grant. Blockchain and bitcoin as a way to lift a country out of poverty-tourism 2.0 and e-governance in the republic of moldova. International Journal of Internet Technology and Secured Transactions, 7(2):115– 143, 2017.

51. T. Ruokolainen, S. Ruohomaa, and L. Kutvonen. Solving service ecosystem governance. In Enterprise Distributed Object Computing Conference Workshops (EDOCW), 2011 15th IEEE International, pages 18–25. IEEE, 2011.

52. A. Saleh, A. El Desouky, and S. Ali. Promoting the performance of vertical recommendation systems by applying new classification techniques. Knowledge- Based Systems, 75:192–223, 2015.

53. M. Schuckert, X. Liu, and R. Law. Hospitality and tourism online reviews: Recent trends and future directions. Journal of Travel & Tourism Marketing, 32(5):608–621, 2015.

54. M. Sigala. Collaborative commerce in tourism: implications for research and industry. Current Issues in Tourism, 20(4):346–355, 2017.

55. Stellar Development Foundation. Stellar Basics - Website. URL: https://www. stellar.org/how-it-works/stellar-basics/. (Accessed September 29, 2018).

31

56. L. Sterling and K. Taveter. The art of agent-oriented modeling. MIT Press, 2009.57. M. Swan. Blockchain thinking: The brain as a dac (decentralized autonomous

organization). In Texas Bitcoin Conference, pages 27–29, 2015.58. N. Szabo. Formalizing and securing relationships on public networks. First

Monday, 2(9), 1997.59. S. Thompson. Haskell: the craft of functional programming, volume 2. Addison-

Wesley, 2011.60. P. Tsankov, A. Dan, D. Drachsler Cohen, A. Gervais, F. Buenzli, and M. Vechev.

Securify: Practical Security Analysis of Smart Contracts. ArXiv e-prints, June 2018.

61. M. Vukoli´c. Rethinking permissioned blockchains. In Proceedings of the ACM Workshop on Blockchain, Cryptocurrencies and Contracts, BCC ’17, pages 3–7, New York, NY, USA, 2017. ACM.

62. I. Weber, X. Xu, R. Riveret, G. Governatori, A. Ponomarev, and J. Mendling.Untrusted business process monitoring and execution using blockchain. In Inter- national Conference on Business Process Management, pages 329–347. Springer, 2016.

63. Y. Wei and M. Blake. Service-oriented computing and cloud computing: Challenges and opportunities. Internet Computing, IEEE, 14(6):72–75, 2010.

64. A. Wright and P. De Filippi. Decentralized blockchain technology and the rise of lex cryptographia. 2015.

65. Z. Xiang, Q. Du, Y. Ma, and W. Fan. A comparative analysis of major online review platforms: Implications for social media analytics in hospitality and tourism. Tourism Management, 58:51–65, 2017.

66. Z. Xiang, V. Magnini, and D. Fesenmaier. Information technology and consumer behavior in travel and tourism: Insights from travel planning using the internet. Journal of Retailing and Consumer Services, 22:244–249, 2015.

67. X. Yingyuan, A. Pengqiang, H. Ching-Hsien, W. Hongya, and J. Xu. Time-ordered collaborative filtering for news recommendation. China Communications, 12(12):53– 62, 2015.

68. Y. Zhang, Q. Ai, X. Chen, and W. Croft. Joint representation learning for top-n recommendation with heterogeneous information sources. In Proceedings of the 2017 ACM on Conference on Information and Knowledge Management, pages 1449–1458. ACM, 2017.