IBAX 개요
특징
IBAX 네트워크(IBAX)는 통합 애플리케이션 개발 환경(IDE)을 갖추고 있습니다. 데이터, 사용자 페이지, 스마트 계약에 대한 다중 수준의 액세스 제어 시스템입니다.
구조와 기능 측면에서 IBAX는 기존의 대부분의 블록체인 플랫폼과는 매우 다릅니다:
IBAX 애플리케이션의 개발과 사용은 생태계(ecosystem)라고 불리는 자체 소프트웨어 환경에서 이루어집니다. 각 생태계는 초기에 생성자에 의해 설정된 회원 자체 규칙을 갖습니다.
데이터베이스 테이블 레코드나 업데이트와 관련된 데이터는 스마트 계약(smart contract)으로 생성된 레지스터(register)에 기반합니다. 대부분의 다른 블록체인 플랫폼에서는 활동이 계정 간의 거래 교환을 기반으로 합니다.
레지스터(register)의 액세스와 생태계 구성원 간의 관계 제어는 스마트 로우(smart laws)라고 불리는 일련의 규칙에 의해 관리됩니다.
아키텍처
네트워크
IBAX는 P2P (peer-to-peer) 네트워크 위에 구축되었습니다.
네트워크의 가디언 노드는 최신 버전의 블록체인 데이터베이스를 저장하며, 이는 IBAX의 블록체인의 최신 상태를 기록합니다.
네트워크 사용자는 가디언 노드 데이터베이스로부터 Weaver 또는 REST API 명령을 통해 요청을 보내 데이터를 수신할 수 있습니다. 사용자의 서명 후, 새로운 요청은 이진 형식의 트랜잭션으로 네트워크로 전송됩니다. 이러한 트랜잭션은 해당 데이터베이스 레코드를 수정하는 명령입니다. 트랜잭션은 블록에 모아지며, 이러한 블록은 모든 네트워크 노드의 블록체인으로 전송됩니다. 각 가디언 노드는 블록 내의 트랜잭션을 처리하여 데이터베이스에서 해당 데이터를 업데이트합니다.
Honor 노드
네트워크에서 새로운 블록을 생성할 권한을 가진 가디언 노드를 명예 노드(honor node)라고 합니다. 명예 노드의 최대 개수는 플랫폼 매개변수 테이블의 number_of_nodes에 정의되어 있으며, 명예 노드의 개수는 제한됩니다.
명예 노드는 IBAX 공개 네트워크의 주요 구성 요소 중 하나입니다. 이는 트랜잭션을 실행하고 검증하며, 다른 노드로부터 트랜잭션 정보를 수집하여 큐에 추가하고, 확인 메커니즘을 사용하여 새로운 블록의 정확성과 유효성을 검증합니다. 일반적으로 명예 노드는 패키징(packaging) 상태와 비패키징(non-packaging) 상태 두 가지 상태를 가집니다.
패키징 상태의 명예 노드는 가장 높은 성능을 발휘합니다. 실행할 트랜잭션 요청을 트랜잭션 큐에서 가져와 트랜잭션의 서명 유효성과 정확성(예: 이체 금액, 트랜잭션 작업 권한, 정확한 트랜잭션 실행)을 검증합니다. 모든 올바른 또는 잘못된 트랜잭션은 블록에 기록됩니다. 잘못된 트랜잭션은 벌점 가스 수수료가 발생하게 됩니다. 실행된 트랜잭션은 브로드캐스팅을 통해 블록과 함께 다른 명예 노드에게 알려집니다.
비패키징 상태의 명예 노드는 주로 블록 검증을 담당하여 패키징 노드가 생성한 블록 내의 트랜잭션이 올바르게 실행되었는지 확인합니다. 이상이 발생할 경우 예외 처리 메커니즘을 트리거하고, IBAX 네트워크는 블록을 롤백하고 다시 검증합니다.
트랜잭션 실행 효율을 보장하기 위해 명예 노드는 지속적으로 트랜잭션 정보를 수집합니다.
거래
트랜잭션은 Weaver를 통해 생성되며, 스마트 계약을 구현하는 데 사용되는 데이터를 포함합니다.
사용자들은 개인 키로 트랜잭션에 서명합니다. 개인 키와 Weaver의 서명 기능은 브라우저, 소프트웨어 클라이언트, SIM 카드 또는 전용 물리 장치에 저장될 수 있습니다. 현재의 구현에서는 개인 키가 ECDSA 알고리즘으로 암호화되어 Weaver 측에 저장됩니다. 모든 트랜잭션은 ECDSA 알고리즘으로 서명됩니다.
트랜잭션의 구조는 다음 형식을 준수합니다:
ID - 구현된 계약의 ID
Params - 계약에 전송된 매개변수
KeyID - 트랜잭션을 보내는 사용자의 ID
PublicKey - 명예 노드의 공개 키
Time - 트랜잭션에서 생성된 타임스탬프
EcosystemID - 트랜잭션이 이루어진 생태계의 ID
ТokenEcosystem - 기본적으로 1인 생태계의 ID이며, 해당 생태계 내의 토큰은 트랜잭션 비용을 지불하는 데 사용됩니다.
네트워크 프로토콜
사용자들이 트랜잭션을 명예 노드에 보내면, 기본적인 형식이 올바른지 확인하기 위해 기본 검증을 거치고, 그 후에 대기열에 추가됩니다. 트랜잭션은 또한 네트워크의 다른 명예 노드에도 전송되어 해당 대기열에 추가됩니다.
명예 노드는 플랫폼 파라미터 full_nodes와 특수한 알고리즘에 의해 결정된 특정 시간 동안 새로운 블록을 생성할 권한을 가지고 있습니다. 명예 노드는 대기열에서 트랜잭션을 가져와 블록 생성기에게 보냅니다. 새로운 블록을 생성할 때, 해당 블록의 트랜잭션도 처리됩니다. 각 트랜잭션은 가상 머신으로 전송되어 트랜잭션 매개변수에 해당하는 계약이 구현되어 데이터베이스의 레코드를 업데이트합니다.
새로운 블록은 다른 네트워크의 다른 명예 노드에게 보내기 전에 오류가 없는지 확인하기 위해 검증되어야 합니다.
다른 명예 노드에게 도착한 새로운 블록은 검증 후에 블록체인에 추가되어 해당 명예 노드의 트랜잭션 처리 및 데이터베이스의 레코드 업데이트가 이루어집니다.
블록 및 거래 검증
새로운 블록을 생성하거나 받은 후에는 다음과 같은 사항들을 모든 다른 명예 노드에서 검증합니다:
수신된 데이터의 첫 번째 바이트는 0이어야 합니다. 그렇지 않으면 수신된 데이터는 블록으로 간주되지 않습니다.
수신된 블록 생성 타임스탬프는 현재 타임스탬프 이전이어야 합니다.
블록 생성 타임스탬프는 새로운 블록을 생성할 수 있는 권한을 가진 명예 노드의 시간 간격과 일치해야 합니다.
새로운 블록의 높이는 기존 블록체인에서 가장 높은 블록의 높이보다 커야 합니다.
블록 내 모든 트랜잭션의 최대 비용을 초과할 수 없습니다.
블록은 해당 노드의 비밀 키로 올바르게 서명되어야 합니다. 서명 데이터는 다음을 포함해야 합니다:
블록의 높이, 이전 블록의 해시, 블록의 타임스탬프, 블록이 위치한 생태계의 ID, 그리고 블록의 명예 노드의 계정 주소
플랫폼 파라미터 full_nodes 배열에서 명예 노드의 위치, 블록의 모든 트랜잭션의 Merkel Root(MrklRoot), 그리고 이전 블록의 Revert 해시
각 트랜잭션의 정확성을 다음과 같은 방법으로 확인합니다:
각 트랜잭션의 해시는 고유해야 합니다.
키로 서명된 트랜잭션은 제한량(max_tx_block_per_user)을 초과할 수 없습니다.
최대 트랜잭션 크기 제한(max_tx_size)을 초과할 수 없습니다.
트랜잭션 시간은 블록 생성 시간보다 크거나, 블록 생성 시간에 600초를 더한 것보다 클 수 없으며, 블록 생성 시간에서 86400초를 뺀 것보다 작을 수 없습니다.
트랜잭션은 올바르게 서명되어야 합니다.
계약을 구현하는 사용자는 트랜잭션 비용을 지불하기 위해 충분한 토큰을 계정에 가지고 있어야 합니다.
데이터베이스
IBAX Network의 기본 데이터 저장 계층은 완전히 공개된 PGSQL
데이터베이스입니다. IBAX 운영 시스템 플랫폼의 권한 디자인을 기반으로, 사용자는 데이터 보안에 대해 걱정할 필요가 없습니다. 객체 지향적인 설계 철학에 따라, IBAX 네트워크는 관계형 PGSQL 데이터베이스를 통해 데이터를 사전 컴파일하고 데이터 처리 효율성을 향상시킵니다.
기술 전문가인 경우에는 다음과 같은 내용에 관심을 가질 수 있습니다. 그렇지 않은 경우에는 건너뛰어도 됩니다.
① 이름에 번호 접두사가 없는 모든 테이블은 IBAX 네트워크 기본 권한 테이블에 속합니다.
② 이름에 번호 접두사가 있는 모든 테이블은 ecoLibs의 권한 테이블에 속합니다.
ECOLIB
일반 사용자들도 IBAX 네트워크 시스템 플랫폼 상에서 쉽게 자체 ecoLib를 생성할 수 있습니다. 우리는 클릭 한 번으로 ecoLib 생성이 가능한 응용 프로그램을 통합 및 개발했습니다.
ecoLib를 생성할 때, 생태계 매개변수와 규칙을 구성하고, 관리자 계정과 과금 모델을 설정할 수 있습니다. 가장 중요한 것은 ecoLib 내에서 DPoA 합의를 더 잘 적용하기 위해, 생성자는 자체 계약을 작성하거나 가져와서 설정할 수 있습니다.
우리는 계약 템플릿을 가져와서 ecoLib 토큰의 빠른 발행을 지원합니다.
합의와 관리 권한의 차이로 인해, ecoLib는 분산형과 중앙집중형으로 나뉩니다. 이들은 유형에 따라 특정한 장점이나 단점을 가지지 않습니다. 서비스 요구에 맞게 적절한 유형을 선택해야 합니다. 현재는 괜찮지만 미래에는 어떻게 될까요? IBAX 네트워크 시스템 플랫폼에서는 ecoLib 매개변수, 합의 메커니즘, 토큰, 거버넌스 방법을 변경할 수 있습니다. 이 모든 것을 ecoLib 관리자나 구성원이 (ecoLib 유형에 따라) 자체 거버넌스 메커니즘에 맡길 수 있습니다.
IBAX 네트워크 시스템 플랫폼에서 ecoLib는 완전한 데이터 제어 권한과 독립적인 데이터베이스 테이블과 필드에 대한 설계 및 액세스 권한을 갖습니다. 데이터 제어 권한 설계에서는 필드가 논리식을 만족할 때 트리거를 지원합니다. 이 기능은 모니터링, 논리 충족, 시간 및 특정 조건에 따른 트리거링과 같은 특수 서비스에서 상상력을 발휘할 수 있도록 합니다.
하나의 ecoLib에는 여러 개의 DApp이 존재할 수 있으며, 각각 독립적인 매개변수를 가질 수 있습니다. ecoLib는 원하는 모든 것을 구현할 수 있는 플랫폼과 같은 역할을 합니다.
생태계 개발자들을 보다 잘 지원하기 위해, 편집, 관리 및 개발 도구 Weaver를 제공하여 생태계 개발, 유지 및 관리 비용을 크게 줄일 수 있습니다. Weaver를 통해 편집, 관리 및 개발을 손쉽게 할 수 있습니다.
Weaver는 사용자 친화적인 인터페이스를 제공하며, 템플릿 기반의 개발을 지원합니다. 템플릿을 사용하여 손쉽게 DApp을 개발하고, ecoLib를 관리하고, 데이터베이스 테이블을 설계할 수 있습니다. Weaver는 개발 프로세스를 간소화하고 생태계 개발자들이 더욱 효율적으로 작업할 수 있도록 도움을 줍니다.
또한, Weaver는 브라우저 기반으로 작동하기 때문에 추가 소프트웨어 설치나 복잡한 설정이 필요하지 않습니다. 사용자는 인터넷 브라우저를 통해 Weaver에 접속하여 개발 작업을 수행할 수 있습니다.
생태계 개발에 대한 지식이 없더라도 Weaver를 사용하여 손쉽게 DApp을 개발할 수 있습니다. Weaver는 풍부한 기능과 템플릿을 제공하여 생태계 개발을 더욱 쉽고 효율적으로 만들어줍니다.
이러한 기능과 도구를 통해 IBAX 네트워크는 생태계 개발자들에게 강력하고 유연한 개발 환경을 제공하며, 생태계의 성장과 발전을 촉진합니다.
IDE
Weaver는 블록체인 애플리케이션을 개발하기 위한 완전한 통합 개발 환경(IDE)을 제공합니다. 이를 통해 소프트웨어 개발자들은 블록체인 기술에 대한 깊은 이해 없이도 애플리케이션을 만들 수 있습니다.
Weaver는 생태계 내에서 애플리케이션을 생성하기 위해 필요한 테이블 관리 도구, 계약 편집기, 페이지 편집기 등의 기능을 제공합니다. 이를 위해 별도의 소프트웨어 모듈의 지원이 필요하지 않습니다.
IDE는 주로 다음과 같은 부분으로 구성됩니다:
생태계 매개변수 목록
계약 편집기
테이블 관리 도구
페이지 편집기 및 시각적 페이지 디자이너
다국어 리소스 편집기
애플리케이션 가져오기/내보내기 기능
Weaver의 IDE를 통해 생태계 내에서 애플리케이션을 개발할 수 있는 강력하고 편리한 환경을 제공합니다. 이를 통해 소프트웨어 개발자들은 블록체인 기술에 대한 지식 없이도 쉽게 애플리케이션을 만들 수 있습니다.
애플리케이션
애플리케이션은 데이터베이스 테이블, 스마트 계약, 사용자 페이지 등의 요소들로 구성된 집합입니다. 구성을 위한 액세스 권한을 가진 생태계에 속하는 요소는 요소 이름에 접두사로 표시됩니다. 예를 들어 @1요소이름
과 같이 요소 이름 앞에 @
기호 다음의 숫자 1
로 생태계 ID를 나타냅니다. 현재 생태계에서 애플리케이션 요소를 사용할 때는 접두사 @1
을 생략할 수 있습니다. 이러한 애플리케이션은 유용한 기능을 수행하거나 다양한 서비스를 구현할 수 있습니다.
테이블
IBAX의 데이터베이스에서 각 생태계는 무제한의 테이블을 생성할 수 있습니다. 특정 생태계의 테이블은 생태계 ID를 포함하는 접두사로 식별되며, Weaver에서는 표시되지 않습니다.
테이블은 특정 계약과 연결되지 않으며, 테이블의 액세스 권한 범위 내의 모든 애플리케이션에서 사용할 수 있습니다.
각 생태계는 애플리케이션 개발을 위한 데이터 테이블 세트를 생성하거나, 테이블 이름 접두사를 지정하여 다른 생태계의 데이터 테이블에 액세스할 수 있습니다.
스마트 로우를 통해 액세스 권한을 구성함으로써 데이터가 테이블에 기록됩니다. 스마트 로우는 권한 관리에 사용됩니다.
테이블 관리 도구
테이블 관리 도구는 Weaver 메뉴의 "Table"에서 찾을 수 있으며, 다음과 같은 기능을 제공합니다:
테이블 데이터 조작
더 나은 데이터베이스 조작을 위해 Needle과 Logicor는 모두 DBFind 함수를 가지고 있습니다. 이 함수는 데이터 테이블에서 값을 검색하고 데이터 배열을 가져옵니다.
스마트 계약 언어에서 DBInsert 함수는 데이터 테이블에 항목을 추가하는 데 사용됩니다. DBUpdate 및 DBUpdateExt 함수는 기존 항목의 값을 업데이트하는 데 사용됩니다. 값이 업데이트되면 데이터 테이블의 해당 데이터가 업데이트되고 블록체인에 새로운 트랜잭션이 추가되지만 모든 이전 트랜잭션은 유지됩니다. 데이터 테이블의 데이터는 수정만 가능하며 삭제할 수 없습니다.
스마트 계약을 실행하는 시간을 최소화하기 위해 DBFind 함수는 동시에 여러 데이터 테이블을 쿼리할 수 없으며 JOIN을 지원하지 않습니다. 따라서 애플리케이션의 데이터 테이블 정규화를 포기하고 가능한 모든 정보를 항목에 저장하거나 다른 데이터 테이블에서 사용 가능한 정보를 반복하는 것이 좋습니다. 이것은 강제적인 조치가 아니라 블록체인 애플리케이션의 필수 조건입니다. 이 경우 저장된 데이터는 완전한 데이터여야 하며 다른 테이블의 동일한 데이터가 업데이트되더라도 해당 데이터는 업데이트되지 않습니다. 이는 관계형 데이터베이스에서 해당 데이터가 동기화되는 것과는 다릅니다.
생태계 매개변수
다음과 같이 Weaver의 메뉴에서 생태계 매개변수 (1_parameters)의 목록을 보고 편집할 수 있습니다. 생태계 매개변수는 다음과 같은 그룹으로 나뉠 수 있습니다:
일반 매개변수: 생태계 생성자의 계정 (founder_account) 및 기타 정보;
접근 권한 매개변수: 애플리케이션 요소에 대한 접근 권한을 정의하는 데 사용됩니다.
- 테이블 구조 변경 (changing_tables);
- 계약 변경 (changing_contracts);
- 사용자 페이지 변경 (changing_page);
- 메뉴 변경 (changing_menu);
- 다국어 자원 변경 (changing_language).
기술적 매개변수: 사용자 스타일 (stylesheet)을 정의하는 데 사용됩니다.
사용자 매개변수: 애플리케이션 작동에 필요한 상수 또는 목록 (쉼표로 구분)을 정의하는 데 사용됩니다.
각 생태계의 매개변수에 대한 편집 권한을 지정할 수 있습니다.
EcosysParam 함수를 사용하여 생태계 매개변수의 값을 검색할 수 있습니다. 함수에 생태계 매개변수 제목을 매개변수로 전달하면 됩니다.
액세스 권한 제어 메커니즘
IBAX는 다중 레벨의 접근 권한 관리 시스템을 갖고 있습니다. 접근 권한을 구성함으로써 계약, 테이블, 사용자 페이지, 생태계 매개변수 등의 애플리케이션 요소를 생성하고 변경할 수 있습니다. 또한, 구성을 통해 접근 권한을 변경할 수도 있습니다.
기본적으로, IBAX 생태계에서는 모든 권한이 생성자에 의해 관리되며, 이는 각 생태계의 MainCondition 계약에서 정의됩니다. 하지만 스마트 법률을 생성한 후에는 접근 제어를 모든 생태계 구성원 또는 일부 구성원에게 양도할 수 있습니다.
접근 권한 제어
접근 권한은 계약 테이블 (1_contracts), 데이터 테이블 (1_tables), 사용자 페이지 테이블 (1_pages), 메뉴 테이블 (1_menu), 코드 블록 테이블 (1_blocks)에 정의됩니다. 이와 관련된 메뉴는 Weaver에서 찾을 수 있습니다.
액세스 권한 관리
접근 권한의 규칙은 해당 계약 표현식인 ContractConditions("@1MainCondition"), ContractAccess("@1MainCondition") 또는 권한 필드에 논리 표현식을 입력하여 구성됩니다. 요청 표현식의 결과가 통과하면(true), 접근이 허용됩니다. 그렇지 않으면 접근이 거부되며 관련 작업이 중지됩니다.
권한을 정의하는 가장 쉬운 방법은 권한 필드에 논리 표현식을 입력하는 것입니다. 예를 들어, $key_id == 8919730491904441614
와 같이 $key_id가 생태계 구성원의 ID를 나타냅니다.
권한을 정의하는 가장 일반적이고 권장되는 방법은 ContractConditions("@1ContractsName1","@1ContractsName2")
함수를 사용하는 것입니다. 계약 이름 ContractsName을 매개변수로 함수에 전달하고, 계약 결과는 논리 표현식의 결과(true 또는 false)여야 합니다.
권한을 정의하는 또 다른 방법은 ContractAccess("@1ContractsName3","@1ContractsName4")
함수를 사용하는 것입니다. 해당 작업을 수행하는 데 필요한 계약 ContractsName을 함수에 매개변수로 전달할 수 있습니다. 예를 들어, amount 열의 권한 필드를 ContractAccess("@1TokenTransfer")
로 구성하면, amount 열의 값을 변경하려면 @1TokenTransfer 계약을 실행할 수 있습니다. 계약 자체에 대한 접근 권한은 조건 섹션에서 관리할 수 있으며, 이는 매우 복잡하며 다른 여러 계약을 포함할 수 있습니다.
독점 권한
비상사태나 생태계 운영에 중요한 상황에서는 생태계 매개변수 목록 (1_parameters)에 여러 가지 특수 매개변수가 있습니다(예: changing_contracts, changing_pages 등). 이러한 매개변수는 모든 계약, 데이터 테이블 및 페이지에 대한 액세스 권한을 정의합니다. 이러한 권한은 키 계약에 의해 구성됩니다.
가상 개인 생태계
IBAX에서는 가상 개인 생태계인 **Cross Ledgers Base (CLB)**를 생성할 수 있습니다. CLB는 표준 생태계와 동일한 기능을 갖지만 블록체인 외부에서 운영됩니다. CLB에서는 계약과 템플릿 언어를 사용하고 테이블을 생성하며, Weaver를 사용하여 애플리케이션을 생성할 수 있습니다. API를 통해 블록체인 생태계의 계약을 호출할 수도 있습니다.
웹 리소스 요청
CLB와 표준 생태계의 주요 차이점은 HTTP / HTTPS 요청을 통해 계약 내에서 웹 리소스를 요청할 수 있는 계약 함수인 (HTTPRequest)와 (HTTPPostJSON)을 사용할 수 있다는 점입니다. 이 함수에 전달되는 매개변수는 URL, 요청 방법(GET 또는 POST), 요청 헤더 및 요청 매개변수입니다..
데이터 읽기 권한
CLB에서는 데이터가 블록체인 내에 저장되지 않지만, 데이터베이스 테이블에 대한 읽기 권한을 부여할 수 있습니다. 개별 열 또는 특정 계약을 사용하여 행의 읽기 권한을 설정할 수 있습니다.
CLB 생성
네트워크에서 CLB 노드를 생성할 수 있습니다. 미리 정의된 대로, CLB 노드 관리자는 CLB 기능을 갖춘 생태계 목록을 사용할 권한이 있으며, 응용 프로그램을 설치하고 새 멤버를 받아들이고 리소스 액세스 권한을 구성하기 위해 생태계 생성자 권한을 가진 사용자를 지정할 수 있습니다.
CLB 사용
CLB를 사용하여 등록 양식을 생성하고 이메일이나 전화를 통해 사용자에게 인증 정보를 보내고 공개적으로 액세스 가능한 데이터를 저장할 수 있습니다. 응용 프로그램을 작성하고 테스트한 다음 블록체인 생태계로 가져올 수 있습니다. CLB에서는 스케줄링 계약 작업을 사용하고, 웹 리소스에서 데이터를 수신하고 해당 데이터를 블록체인 생태계로 전송하기 위해 오라클 기계를 생성할 수 있습니다.