NEAR Document Cloud 소개 — 문서 관리를 위한 분산 접근 방식

NEAR Document Cloud 소개 — 문서 관리를 위한 분산 접근 방식

 

Web3 문서 관리 방식

문서에 서명, 관리, 저장 및 수정하는 강력하고 신뢰할 수 없는 솔루션입니다.

모든 것은 차세대 레이어 1 블록체인 NEAR 플랫폼에 의해 구동됩니다.

NEAR는 이 글을 쓰는 시점에서 가장 인기 있는 블록체인은 아니지만 적어도 이론적으로 대중 소비자 중심 앱인 분산형 애플리케이션을 위해 선택하기에 매우 좋은 기반을 가지고 있습니다.

저렴하고 빨라야 하고 확장 가능해야 하며 사용자가 사전 설정 없이 쉽게 들어갈 수 있어야 하며 환경에도 영향을 미치지 않아야 합니다. 이더리움과 비교할 때 NEAR는 이를 가지고 있으며 이러한 사용 사례에 유용합니다.

우리 모두는 다양한 당사자와 문서 또는 계약에 서명하거나 최소한 인정합니다. 은행, 부동산 중개인 및 집주인이 될 수 있습니다. 소비자 및 기타 사업자와의 계약을 통해 공식화된 노력을 하는 기업도 마찬가지입니다.

두 당사자를 묶는 단일 계약은 여러 개정판을 발행할 수 있으므로 이 모든 것의 관리(예: 저장, 서명, 발행)가 복잡합니다.

문서 관리의 마찰을 줄이기 위한 이러한 솔루션이 점점 더 많이 있지만 이 글을 쓰는 시점에서 이러한 솔루션 중 어느 것도 web3를 기반으로 하지 않습니다. 그렇기 때문에 NEAR Document Cloud는 이 문제에 대한 또 다른 솔루션이지만 이번에는 탈중앙화가 수반됩니다.

UI 레이어는 현재 와이어프레임 단계에 있습니다. 일반적으로 제 개인적인 생각은 어떤 UI든 기술적인 사람들 사이의 커뮤니케이션 수단이라도 UI가 없는 것보다 훨씬 낫다는 것입니다. 자동으로 모든 사람을 같은 페이지로 만들고 아이디어를 명확하게 이해합니다.

NEAR 문서 클라우드의 가장 중요한 프레임을 논의하고 전체 프로젝트의 목적에 대한 최선의 설명으로 취급합시다

상장 계약

여기에 로그인한 사용자가 발행했거나 발행한 모든 계약이 표시됩니다. 이것은 사용자가 수행할 작업을 즉시 볼 수 있는 일종의 환영 페이지입니다. 즉, 기한 전에 새로 발행된 계약에 서명합니다.

모든 문서 목록

계약 목록에서 내가 발행한 계약과 나를 위해 발행한 계약(내가 서명해야 하는 곳) 간의 명확한 차이도 볼 수 있습니다.

새로운 계약서 발급

매우 간단한 형식으로 새로운 계약 프로세스 추가 시각화

모든 사용자가 계약을 추가할 수 있습니다. 계약을 추가하려면 초기 문서 버전 및 의도된 서명자에 대한 최소한 ipfs 링크를 입력해야 합니다. 나머지 모든 세부 사항은 잠재적인 확장 및 이를 저장할 위치(온체인 대 오프체인)에 대한 결정의 문제입니다.

계약서 서명

사용자는 의도된 서명자임을 명시적으로 표시한 경우에만 계약서에 서명할 수 있습니다. 사용자 역할을 수행하기 위해 발행되지 않은 계약에 서명하려고 하면 throw(reject tx)됩니다.

아직 서명되지 않은 신용 카드 사업자와의 계약

위 이미지에서 신용 카트 운영자와의 계약을 볼 수 있습니다. not signed 업데이트되었기 때문에 발급자가 추가되었습니다. revision two 그리고 이 계약이 공식적으로 시행되려면 다시 서명해야 합니다. 이것은 지갑 버튼으로 서명을 클릭하고 tx를 승인하면 쉽게 달성할 수 있습니다.

새 버전 추가

사용자는 자신이 발행한 계약에 대해서만 개정을 추가할 수 있습니다. 다른 사람이 발행한 계약에 수정 사항을 추가하려고 하면 거래가 거부됩니다.

새 개정판을 추가하면 별도의 화면에서 잠재적으로 달성할 수 있으며 입력하기만 하면 됩니다. ipfs link 새 문서로. 이전 링크, 서명 기록 또는 기타 세부 정보와 같은 계약의 다른 모든 세부 정보는 이 단계에서 읽기 전용이어야 합니다.

새 개정을 추가하면 전체 계약이 다음과 같이 설정됩니다. isSigned : false 이미 서명되었는지 여부에 관계없이 상태입니다. 조건이 변경되었으며 서명자가 명시적으로 다시 서명하지 않으면 계약이 자동으로 시행/서명될 수 없습니다.

계약 계약

계약 클래스에는 다음이 포함되어야 합니다.

• issuer 발행자 지갑 주소를 저장하기 위해
• isSigned 계약의 최신 개정 서명 상태를 추적하기 위해
• versions 모든 버전의 계약을 추적하기 위해

또한, 계약서에 서명할 때와 새로운 개정을 추가할 때의 두 가지 방법이 있습니다.

클라우드에 새로운 계약을 추가하는 생성자 및 팩토리 함수가 있는 계약 클래스

그것을 분해하고 코드를 청크로 논의합시다.

constructor(public uri: string, public signer: string) {
this.issuer = Context.sender;
this.isSigned = false;
this.versions = new PersistentVector(`${uri}-v`);
this.versions.push(uri);
this.uri = uri;
}

생성자에서 우리는 각 계약의 서명자가 메서드 호출 수신자로 설정되어 있고 처음에는 서명되지 않았으며 버전 컬렉션에 첫 번째 버전이 추가되었음을 알 수 있습니다. PersistenVector) 및 그 uri 현재 URI가 나중에 변경되는 경우 초기 URI, 이벤트입니다.

@mutateState()
addAgreementVersion(version: string): void { assert(Context.sender == this.issuer, "Only issuer can update
agreement");
this.versions.push(version);
this.isSigned = false;
}

addAgreementVersion 수신자가 초기 발급자인지 확인하고 재설정합니다. isSigned 플래그를 false로 설정하고(새 개정을 추가한 후 조건이 분명히 변경되었으므로 전체 계약에 다시 서명해야 함) 새 버전을versions수집

@mutateState()
signAgreement(): void{
assert(Context.sender == this.signer, "You're not allowed to sign this");
this.isSigned = true;
}

signAgreement 수신자가 서명자로 표시된 것인지 확인하고 그렇다면 플래그를 변경합니다. isSigned 사실로.

계약 계약 사용

여기에서 이러한 함수는 일종의 팩토리 클래스를 시뮬레이션하여 모든 계약이 포함된 레지스터가 있는지 확인하고 각 클래스의 함수를 호출하여 클래스 수준에서 작동하는 방식을 보여줍니다.