평행우주 : world 1

[ 기획 ] 프로덕트 스펙 작성 방법

parallelworlds — Thu, 14 Jul 2022 06:15:33 +0900

On Writing Product Specs

If you’re a PM at a medium-to-large org, you should be writing product specs. Learn why and how along with a detailed example.

goberoi.com

요약

잘쓰여진 프로덕트 스펙 리스트는 훌륭한 소프트웨어를 구축하는데 중요하게 작용한다.

비판적 사고, 커뮤니케이션 확장, 책임감 등이 더 높은 품질과 더 낮은 데드라인 위험, 더 적은 시간 낭비로 이어지게 한다.

왜 프로덕트 스펙을 작성하는가?

1. 비판적 사고

글을 먼저 작성함으로써 코딩, 디자인, QA 등과 같은 리소스가 많이 들어가는 작업 전에 구체적으로 생각할 수 있게 한다.

2. 효율적인 의사소통

프로덕트가 진행될 때 마주하게 되는 엔지니어, 디자인, 재무, 관리자 등 다양한 이해관계자에게 일괄적이고 모호하지 않게 제안할 수 있게 한다.

3. 책임감

항상 측정 가능한 목표를 공개적으로 노출함으로써 팀의 인센티브를 조정하고, 책임감을 느끼게 한다

프로덕트 스펙에는 무엇이 포함되어야 하는가?

1. 문제

해결하고자 하는 문제와, 문제를 다뤄야 할 가치를 논리적으로 서술해야한다.

2. 측정 가능한 목표

명확한 결과물과 달성가능한 결과를 시각화한다.

3. 맥락

팀원이 문제 상황을 이해하고 납득할 수 있는 증거를 제시해야 한다. (가정, 사례, 논리 등)

4. 상세한 솔루션

제안은 팀이 바로 착수할 수 있을 정도로 상세해야 한다. 인간 두뇌가 작성하는 코드와 같다고 생각해라.

5. 타임라인

날짜와 이정표를 나열한다. 시작은 모호할 수 있지만, 마지막 검토에서는 구체화 되어야 한다

프로덕트 스펙 작성법

1. 빠른 초안 작성 (1 시간)

예제 product spec/notes

2. 30분짜리 회의를 두어 번 진행한다. 이때 회의는 소규모로 유지하고, 가능한 적은 수의 사람들로 진행하는 것이 좋다 (1-4 시간)

3. 프로덕트 스펙 작성 및 편집. 비판적 사고와 글쓰기로 여러 아이디어를 결합하고, 편집을 통해 간결하고 명확하게 만든다. (반나절-3 일)

4. 1시간 리뷰 게시 및 설정

5. 검토 (1 시간)

Example Spec Notes - Live Chat

This is an example early draft product spec/notes, written as part of this blog post. Problem: Conversion sucks. 18% but should be able to do 30% (need source). What else have we tried here, and why is this worth trying? Need to look up our past support ca

docs.google.com

Example Spec - Live Chat

This is an example product spec, written as part of this blog post. Some notes: Commentary will appear with this light blue background throughout the doc. Read the doc once through while ignoring the blue bits, then go back and reread. Links don’t go any

docs.google.com

[Rust] 러스트 데이터 타입 : scalar, Compound, 문자열

parallelworlds — Fri, 8 Apr 2022 21:07:19 +0900

Rust 데이타 타입

Statically Type Language

프로그램 상의 모든 데이터 타입을 컴파일 시점에 결정한다

컴파일 시점에, 각 타입에 위배되는 코드가 있을 경우 에러가 발생한다

let으로 선언된 변수의 경우, 데이터 타입이 결정되지 않은 경우 러스트 컴파일러가 추론 결정한다

스칼라 타입(Scalar Type)

하나의 값을 갖는 타입

정수형, 부동소수점형, 불린형, 문자형이 있다

정수형

fn main() {
    let a: i32 = 1_000_000; // 10진수, 백만 | 가독성을 높이기 위해 _사용 가능
    let a = 0xff;    // 16진수
    let a = 0o15;    // 8진수
    let a =  0b1111_1111; // 2진수
    let a: u8 = b'A';   // 바이트 (앞에 b를 붙임)
}

i8, u16, i32, u64, i128, usize 와 같이 정수를 포함하는 타입

부호가 있을 경우 : i

부호가 없는 경우 : u

부동소수점형

let a: f32  = 3.14;   // f32
let b = 3.14;         // f64

f32, f64 존재

부동소수점 타입을 지정하지 않는 소수값은 컴파일러가 디폴트로 f64를 지정

불린형

let a: bool = false;

문자형

let a: char = 'A';    // U+0041

char 키워드를 사용

4바이트 크기

U+0000 ~ U+D7FF와 U+E000 ~ U+10FFFF 범위의 유니코드 스칼라 값을 가질 수 있다.

이러한 유니코드 문자가 아닌, 1 바이트의 값을 표현하기 위해서는 u8 타입을 사용

복합 타입(Compound Type)

여러개의 값들로 구성된 타입

배열(Array)과 튜플(Tuple)

배열(Array)

let arr: [i32; 3] = [1, 2, 3];   // 3개의 정수배열 
 
println!("{}", arr[0]);   // 배열 첫번째 요소 출력
 
println!("{:?}", arr);    // 배열전체를 출력

동일한 데이타 타입을 갖는 요소들의 집합

고정된 길이를 갖는다

러스트에서 배열은 스택에 할당된다

배열값을 지정할 때, [1; 100] 과 같이 세미콜론을 사용하면, 이는 [1, 1, ..., 1] 와 같이 1을 100개 지정하는 것

튜플(Tuple)

let dat: (i32, char, bool) = (1, 'A', true);
let usr = ("Tom", 'B');

여러 데이타 타입의 값들을 하나로 묶은 것

괄호를 사용하고 각 타입이나 값들을 콤마로 분리

튜플이 한번 정의되면, 새로운 요소를 추가하거나 기존 요소를 삭제할 수 없다

let dat: (i32, char, bool) = (1, 'A', true);
let a = dat.0; //1
let b: char = dat.1; //A
let c: bool = dat.2; //true

let dat: (i32, char, bool) = (1, 'A', true);
let (a, b, c) = dat; //Destructuring : 튜플 전체를 읽어 여러 변수들에 나누어 할당

문자열 타입

일반적으로 &str 타입과 String 타입을 사용

&str

fn main() {
    let s = "hello";    // let s: &'static str = "hello"; 와 동일
    println!("{}", s);
}

//변수 s는 &'static str 타입으로 문자열 리터럴 "hello" 에 대한 레퍼런스(reference)

문자열을 표현하는 Primitive 문자열 타입

str 타입은 항상 레퍼런스이기 때문에, 실제 코드에서는 &str 와 같이 사용

문자열 리터럴은 코드 바이너리에 직접 저장

프로그램의 실행기간 동안 계속 존재하여 'static 이라는 키워드 추가

&str의 &는 레퍼런스를 의미

문자열 리터럴을 변수에 할당할 때 사용 (&'static str 타입)

다른 변수가 소유한(owned) 문자열의 일부를 슬라이스하여(&str 타입) 가져올 때 사용

//변수 s가 소유한(own) 문자열의 일부 범위를 문자열 슬라이스하여 변수 sub에 넣는 예제
fn main() {
    let s = "hello";  
    let sub: &str = &s[1..4]; //&s[1..4] 는 요소1 부터 요소3까지의 범위 즉 "ell" 을 가리킨다
    println!("{}", sub);    // "ell" 출력
}

범위(range)를 지정할 때 [시작..마지막] 와 같이 표현하는 마지막위치는 실제 마지막위치의 다음 인덱스를 넣는다

fn main() {
    let s: &'static str = "hello";  
 
    // &str 타입을 String 타입으로 변환
    let x: String = s.to_owned();
 
    println!("{}", x);
}

&str 타입을 String 타입으로 변환하기 위해서는 to_owned() 함수 사용

to_string()은 임의의 타입을 String 타입으로 변환

to_string()은 많은 메모리를 사용하므로 &str 타입에서는 to_owned() 함수를 사용하는 것이 좋다

String

fn main() {
    let s = String::from("hello");  
    // String::from() > 문자열 리터럴을 String 타입으로 
    // let s: String = "hello".to_owned(); // 동일
 
    println!("{}", s);
}

Heap 메모리 상에 문자열을 저장

문자열 메모리에 새 문자들을 추가하거나 수정할 수 있다

fn main() {
    let mut s = String::new();   // 새로운 empty string 생성
    // 빈 문자열이므로 문자를 추가하기 위해 변수를 mut로 만들어준다
    s.push('H');           // 문자 추가
    s.push('i');           // 문자 추가
    s.push_str(" Tom");  // 문자열 추가
     
    println!("{}", s);  // "Hi Tom" 출력
}

fn main() {
//String::replace() 함수를 사용 > 문자열의 일부를 다른 문자들로 치환
    let mut s = String::from("Hello Bill");
    s = s.replace("Hello", "Hi");
     
    println!("{}", s); // "Hi Bill" 출력
}

[Rust] 러스트 변수(variable) 특성

parallelworlds — Fri, 8 Apr 2022 20:15:29 +0900

변수 선언

let a = 100;   
let b = 3.14;

변수의 데이터 타입이 정의되지 않은 경우 러스트 컴파일러는 타입을 추론한다

(상수는 항상 타입을 지정해야 한다)

let c: u32 = 12345;  //32비트 정수
let d: f32  = 3.14;  //32비트 부동소수점
let e: bool = true;

데이터 타입을 명시적으로 지정하는 경우, 변수명 뒤에 콜론을 찍고, 데이터 타입을 적는다

변수의 불변성 (디폴트)

let a = 100;
a = a + 1;    
// 에러: cannot assign twice to immutable variable `a`
println!("{}", a);

변수는 불변성을 갖는다

따라서 변수에 값이 한 번 지정되면 이후에는 그 값을 변경할 수 없다

가변적 변수 (예외)

let mut a = 100;
a = a + 1;    // 에러 없음
println!("{}", a);

변수의 데이터가 변경되어야 하는 경우

변수 앞에 mut 를 입력하면 된다

상수

fn main() {
    const PI: f64 = 3.141592;
 
    let area = PI * 5.0 * 5.0;
    println!("{}", area);
}

상수는 항상 불변의 값을 갖는다

const로 선언하며, 항상 데이터 타입을 지정해야 한다

Shadowing

fn main() {
    let a = 1;        // 변수 a는 정수형
    println!("{}", a);

    let a = "hello";  // 변수 a는 문자열
    println!("{}", a);
}

"let"으로 변수를 사용한 경우, 한 코드 Scope에서 동일한 변수명을 let으로 여러 번 정의할 수 있다

새로 정의하는 시점에 이전의 변수 a는 잊게 되고 2를 갖는 a만을 기억하게 된다

fn main() {
    let a = 1;
    let a = 2;
    {
        let a = a + 1;
        println!("{}", a); // 출력: 3
    }

    println!("{}", a); // 출력: 2
}

fn main() {
    let mut a = 1;
    a = 2;
    {
        a = a + 1;
        println!("{}", a); // 출력: 3
    }

    println!("{}", a); // 출력: 3
}

[Rust] 러스트 Cargo 사용법

parallelworlds — Fri, 8 Apr 2022 19:21:04 +0900

Cargo 란?

rust 프로젝트/패키지 매니저

rust 빌드시스템 도구

새 프로젝트를 만들거나 프로젝트 빌드 시 사용

프로젝트가 필요로 하는 종송 패키지들을 다운 받을 때도 사용

Cargo : 프로젝트 생성

myproject1 생성 시 명령어

$ cargo new myproject1
$ cd myproject1

myproject1 폴더가 생성된다

또한 Cargo.toml 파일과 src/main.rs 파일이 생성된다

Cargo.toml 파일은 nodejs의 package.json 와 비슷한 역할을 한다

( 프로젝트의 기본정보와 패키지 목록 관리 텍스트파일)

숫자로 시작하는 파일은 만들 수 없다

Cargo : 빌드와 실행

소스파일들은 src폴더 안에 들어간다

cargo 빌드를 하면 실행파일은 target 폴더 안에 만들어진다

cargo new aa 로 만들어진 프로젝트 폴더 안에서 cargo build를 수행하면,

코드가 빌드되고 target 폴더 안에 실행파일 aa이 생성된다

빌드와 실행을 함께 하고 싶을 때는 cargo run 명령을 수행하면 된다

$ cargo run

[실습 | 블록체인] Truffle을 이용한 다량의 ERC-721 개발하기

parallelworlds — Thu, 7 Apr 2022 17:12:42 +0900

대량 민팅 ... ! 나도 해보고 싶다

한 두개씩 ERC-721 을 배포해보고,,

보통의 NFT 프로젝트처럼 만들어보고 싶어졌다

여러 요소들을 만들고 희귀성도 넣어보고 500개 정도 민팅해보는 게 목표 !

중간중간 에러가 나서,, 시간은 좀 더 걸릴 거 같지만

되는대로 업데이트 할 예정이다

⛑ 개발 환경

truffle

rinkeby

opensea testnet

pinata

openzeppelin

Solidity

react

참고자료 : Ethereum for JS Developer

‍ 만들어 볼 것 : 500개 정도의 랜덤한 조합의 ERC-721 토큰 개발

ERC-721 토큰을 만들자 !

대략 500개 정도 발행하되, 희귀성도 넣어보자 !

오픈씨 테스트넷에 올려보자 !

설계 순서

1. 속성 이미지 만들기

2. 이미지 랜덤 조합 스크립트 작성

3. 생성된 이미지 IPFS 업로드 후 메타정보 생성 (JSON형식으로 IPFS 업로드)

4. ERC-721 컨트랙트 작성

5. 리액트로 아주 간단한 NFT 발행 가능한 어플리케이션 만들기

6. 오픈씨 테스트넷에 올리기

[실습 | Solidity] 블록체인을 사용한 DID 백신 접종 인증서 개발

parallelworlds — Thu, 7 Apr 2022 15:55:21 +0900

SSI, DID가 매력적인 이유

우리는 신원과 식별자를 종종 혼동하는 경우가 있다.

우리가 신원하면 흔히 떠올리는 신분증, 여권, 인증서 등은 신원이 아닌 식별자다.

신원은 보다 더 개인적이고, 자기주권적 인간인 내 자신의 통제하에 있는 것이다.

문제는, 우리의 신원과 관련된 대부분의 것들이 조직의 관리 편리성을 위한 방법대로

우리 자신의 통제가 없는 상태에서 이뤄지고 있다는 것이다.

우리는 우리의 신원을 통제할 필요가 있다

SSI의 발전은 바로 그 시작점이다

✍ SSI, DID에 대한 짧은 정리글

[SSI | DID] SSI 자기주권 신원증명 인증

SSI 자기주권 신원증명 대부분의 SSI 플랫폼은 블록체인 기술을 기반으로 개발 모든 SSI 플랫폼이 블록체인을 통해 개발될 필요는 없다 블록체인 분산원장의 특징 블록체인에 참여하는 모든 사

1parallelworlds.tistory.com

[SSI | DID] DID(Decentralized IDentifier) 구성요소, 생성과 사용과정

DID(Decentralized IDentifier) 사용하는 사람 스스로 생성하고 제어할 수 있는 분산형 식별자 DID를 사용하는 객체에 대한 식별자로 사용될 뿐만 아니라, 인증 수단인 DID document를 참조할 수 있는 URI 역

1parallelworlds.tistory.com

[SSI | DID] DID Document 구성요소 : id

DID Document DID Document에는 DID의 소유권을 증명할 수 있는 인증 수단이 포함된다 +) 대부분의 DID 플랫폼은 DID와 DID doc 생성 시 비대칭키를 함께 생성 생성한 비대칭키의 비밀키는 본인이 보관하고,

1parallelworlds.tistory.com

‍ 만들어 볼 것 : 백신 접종 증명서

코로나 19 백신 접종을 받았음을 검증 가능한 자격 증명을 DID로 구현해보자

W3C의 권고사항에 따르면 다음과 같은 사항을 설계 시 참고해야 한다

>> 발급자가 선택적 공개를 지원하는 소프트웨어가 없는 경우에도,

선택적 공개를 지원하는 검증가능한 크리덴셜을 발급할 수 있는 수단 제공

>> 발급자는 선택적 공개를 지원하는 검증가능한 크리덴셜을 발급 가능

검증은 어떤 발급자에게도 검증자의 신원을 공개하지 않아야 함

>> issuanceDate

크리덴셜이 유효한 날짜와 시간을 나타내는 문자열 값

>> proof

변조를 감지하고 크리덴셜 또는 프레젠테이션의 소유권을 확인하는 데 사용할 수 있는 암호화 프루프

>> credentialStatus

id , type 등이 포함되어야 한다

이보다 더더 많은데,, 일단 도전해볼 수 있을만한 것들만 추려보았다.

일단 이번에는 위의 참고사항도 다 포함하지 않은

아주 간단한 DID 개발을 해볼 예정이다

코드 분석

OwnerHelper

// Owner만 실행할 수 있는 컨트랙트
abstract contract OwnerHelper {
    address private owner;

    event OwnerTransferPropose(address indexed _from, address indexed _to);

    modifier onlyOwner() {
        require(msg.sender == owner);
        _;
    }

    // 함수 호출 시 owner = msg.sender로 자동 설정
    constructor() {
        owner = msg.sender;
    }
     // owner 권한을 가진 자가 다른 주소로 권한 위임
    function transferOwnership(address _to) public onlyOwner {
        require(_to != owner);
        require(_to != address(0x0));
        owner = _to;
        emit OwnerTransferPropose(owner, _to);
    }
}

IssuerHelper

// IssuerHelper는 Issuer을 추가 또는 삭제할 수 있다
// 그 기능은 onlyOwner로 제한되어 Owner만 제어 가능
abstract contract IssuerHelper is OwnerHelper {
    mapping(address => bool) public issuers;

    event AddIssuer(address indexed _issuer);
    event DelIssuer(address indexed _issuer);

    modifier onlyIssuer() {
        require(isIssuer(msg.sender) == true);
        _;
    }

    constructor() {
        issuers[msg.sender] = true;
    }

    function isIssuer(address _addr) public view returns (bool) {
        return issuers[_addr];
    }

    function addIssuer(address _addr) public onlyOwner returns (bool) {
        require(issuers[_addr] == false);
        issuers[_addr] = true;
        emit AddIssuer(_addr);
        return true;
    }

    function delIssuer(address _addr) public onlyOwner returns (bool) {
        require(issuers[_addr] == true);
        issuers[_addr] = false;
        emit DelIssuer(_addr);
        return true;
    }
}

CredentialBox : mapping, struct

// Credential 발행, 확인
contract CredentialBox is IssuerHelper {
    uint256 private idCount; // Credential이 한 주소에 하나씩만 발급받게 한다
    mapping(uint8 => string) private vaccineEnum; // 백신 종류
    mapping(uint8 => string) private statusEnum; // 접종 상태 (횟수)

    // VC를 구현하기 위한 구조체
    struct Credential {
        uint256 id; // index 순서 표기하는 idCount
        address issuer; // 발행자
        uint8 vaccineType; // 백신 증명서 타입
        uint8 statusType; //접종 상태 (횟수)
        string value; // 크리덴셜에 포함되어야 하는 암호화된 정보.
        // 중앙화된 서버에서 제공하는 신원, 서명 등이 JSON 형태로 저장됨
        uint256 createDate;
    }

    // 주소값으로 발급된 크리덴셜 확인
    mapping(address => Credential) private credentials;

CredentialBox : constructor

    constructor() {
        idCount = 1;
        vaccineEnum[0] = "미접종 권고 대상자"; //약물알러지, 기저질환 등
        vaccineEnum[1] = "PFI"; //화이자
        vaccineEnum[2] = "JOH"; //얀센
        vaccineEnum[3] = "AST"; //아스트라제네카
        vaccineEnum[4] = "NOV"; //노바백스
        vaccineEnum[5] = "MOD"; //모더나
        statusEnum[0] = "미접종"; // 접종 상태 (횟수)
        statusEnum[1] = "1회차";
        statusEnum[2] = "2회차";
        statusEnum[3] = "3회차";
        statusEnum[4] = "4회차";
    }

CredentialBox : claimCredential

// claimCredential 함수로 Credential 발행
    function claimCredential(
        address _vaccineAddress,
        uint8 _vaccineType,
        uint8 _vaccineStatusType,
        string calldata _value
    ) public onlyIssuer returns (bool) {
        Credential storage credential = credentials[_vaccineAddress];

        // credential의 id가 0일 경우에만 함수 작동
        require(credential.id == 0);
        credential.id = idCount;
        credential.issuer = msg.sender;
        credential.vaccineType = _vaccineType;
        credential.statusType = 0;
        credential.value = _value;
        credential.createDate = block.timestamp; //block.timestamp를 활용해 크리덴셜을 클레임한 시간 저장

        idCount += 1;

        return true;
    }

CredentialBox : getCredential, addStatusType, changeStatus

// getCredential 함수로 Credential을 발행한 주소에서 VC확인
    function getCredential(address _vaccineAddress)
        public
        view
        returns (Credential memory)
    {
        return credentials[_vaccineAddress];
    }

    function addVaccineType(uint8 _type, string calldata _value)
        public
        onlyIssuer
        returns (bool)
    {
        require(bytes(vaccineEnum[_type]).length == 0);
        vaccineEnum[_type] = _value;
        return true;
    }

    function getVaccineType(uint8 _type) public view returns (string memory) {
        return vaccineEnum[_type];
    }

    // bytes로 변환하여 길이로 String이 null인지 검사
    // 내부 statusEnum의 Type이 중복되는 타입이 존재하는지 검사
    function addStatusType(uint8 _type, string calldata _value)
        public
        onlyIssuer
        returns (bool)
    {
        require(bytes(statusEnum[_type]).length == 0);
        statusEnum[_type] = _value;
        return true;
    }

    function getStatusType(uint8 _type) public view returns (string memory) {
        return statusEnum[_type];
    }

    // 특정 사용자의 상태 변경
    // statusType의 값을 가져와 변경한다
    function changeStatus(address _vaccine, uint8 _type)
        public
        onlyIssuer
        returns (bool)
    {
        require(credentials[_vaccine].id != 0);
        require(bytes(statusEnum[_type]).length != 0);
        credentials[_vaccine].statusType = _type;
        return true;
    }
}

전체 코드

GitHub - potterpeter/vaccine-DID: vaccine DID

vaccine DID. Contribute to potterpeter/vaccine-DID development by creating an account on GitHub.

github.com

[SSI | DID] DID Document 구성요소 : id

parallelworlds — Thu, 31 Mar 2022 12:05:23 +0900

DID Document

DID Document에는 DID의 소유권을 증명할 수 있는 인증 수단이 포함된다

대부분의 DID 플랫폼은 DID와 DID doc 생성 시 비대칭키를 함께 생성

생성한 비대칭키의 비밀키는 본인이 보관하고,

공개키는 DID doc에 넣어 블록체인에 저장

예) DID 소유권을 증명하는 DID Auth 방법 중 하나

소유권 증명 예시

>> 사용자가 검증기관에 did:ethr:1234가 본인의 DID 라고 주장한다

>> 검증기관은 사용자의 DID 를 통해 사용자 DID Document 가 저장된 위치를 확인하고 획득한다

>> 검증기관은 획득한 DID Document를 이용하여 해당 DID 가 사용자가 생성한 DID임을 인증해보라는 challenge 전송

>> challenge를 받은 사용자는 인증을 위해 challenge에 해당하는 response를 전송

>> response를 받은 검증기관은 사용자의 DID Document에 포함된 공개키를 이용하여 검증

DID Document에는

@context,

id,

publicKey,

authentication,

service 라는 중요 항목이 있다

DID Doc - id

DID Document의 id 항목에는 id를 통해 식별되는 객체(사람, 물건 등)의 DID가 들어있다

일반적으로 DID와 DID Doc를 생성하고 등록한 사람의 DID가 id 항목에 들어간다

DID Document 생성 및 요청과정

>> 사용자는 DID를 생성한 후

>> DID Doc를 생성

DID Doc의 id 값에는 생성했던 DID 외 향후 소유권 인증(DID Auth)에 필요한 값 입력

>> DID Doc 생성을 완료하면 DID method에 정의된 저장소에 DID Doc 등록

DID Document 반환 과정

>> DID Doc 생성 후 사용자가 검증기관에게 자신의 DID를 알려주면

>> 검증기관은 사용자의 DID method에 명시된 블록체인에 DID Doc를 반환해 줄 것을 요청

>> DID Doc 반환 요청을 받은 블록체인은 저장된 DID Doc 중 id 항목이 검증기관이 요청한 DID 와 동일한 DID Doc를 찾아서

>> 검증기관에게 반환

DID를 사용하는 당사자만이 직접 did를 생성할 수 있는 것은 아니다

DID로 식별되는 사용자 대신 다른 인물이 DID를 생성하고 인증하는 경우,

사용자를 식별하기 위한 DID는 DID Doc의 id 항목에 들어가고,

사용자의 DID를 대신 생성해주고 해당 DID의 소유권을 인증할 수 있는

DID 생성자는 controller 항목에 들어가게 된다

[SSI | DID] DID(Decentralized IDentifier) 구성요소, 생성과 사용과정

parallelworlds — Thu, 31 Mar 2022 11:32:21 +0900

DID(Decentralized IDentifier)

사용하는 사람 스스로 생성하고 제어할 수 있는 분산형 식별자

DID를 사용하는 객체에 대한 식별자로 사용될 뿐만 아니라,

인증 수단인 DID document를 참조할 수 있는 URI 역할까지 동시에 수행가능하다

분산형 식별자

동일한 식별자가 생성되지 않은 구조로 만들어진다

URI

인터넷에 존재하는 자원을 나타내는 주소

여기서, DID는 즉 DID doc의 위치를 나타낼 수 있는 주소

DID 구성요소

DID scheme

URI가 어떤 프로토콜을 사용해서 자원에 접근하는지 명시

DID method

DID doc가 어떤 저장소에 저장되어 있는지 보여준다

예) DID method에 btcr이 명시되어 있으면 비트코인에 접근하여 DID doc를 검색

method-specific identifier

DID method 가 가리키는 저장소 내 DID doc가 저장된 정확한 위치를 검색

예) DID method를 참조해서 비트모인 블록체인에 접근한 후 method-specific identifier를 이용해 검색하면

DID doc을 가져올 수 있다

DID와 DID document의 사용 과정

>> 사용자 1은 DID와 DID doc을 생성한 후,

>> DID doc은 DID method에 명시된 저장소에 저장

>> 사용자 2가 사용자 1의 DID 주소를 알고 있다면,

>> DID에 명시된 저장소와 저장소 내 method-specific identifier가 가르키는 위치에 저장된 사용자 1의 DID doc을 획득 가능

DID와 DID document의 생성

대부분의 DID 플랫폼은 DID와 DID doc 생성 시 비대칭키를 함께 생성

생성한 비대칭키의 비밀키는 본인이 보관하고,

공개키는 DID doc에 넣어 블록체인에 저장

DID의 생성 구조는 플랫폼마다 조금씩 다르다

예)

Sovrin 블록체인의 DID는 비대칭키 생성 시 공개키의 일부분이 method-specific identifier가 된다

> DID는 did:sov:공개키 구조로 생성

이더리움은 어카운트 주소가 method-specific identifier가 된다

> DID는 did:ethr:어카운트 구조로 생성

[SSI | DID] SSI 자기주권 신원증명 인증

parallelworlds — Thu, 31 Mar 2022 03:23:26 +0900

SSI 자기주권 신원증명

대부분의 SSI 플랫폼은 블록체인 기술을 기반으로 개발

모든 SSI 플랫폼이 블록체인을 통해 개발될 필요는 없다

블록체인 분산원장의 특징

블록체인에 참여하는 모든 사람이 동일한 원장을 소유하고 관리

모든 정보가 암호화되어 Append-only 방식으로만 원장에 저장된다

즉, 한 번 원장에 기록된 정보는 절대 수정할 수 없다(불가변성 특성)

블록체인 참여자는 스마트 컨트랙트를 통해 분산원장에 정보를 기록하거나 불러올 수 있다

블록체인 합의 특징

블록체인에 참여하는 모든 사람이 동일한 원장을 소유하기 때문에

이러한 조건을 만족시키기 위해 참여한 노드의 합의가 필요하다

SSI 특징

블록체인에 저장된 데이터는 이미 구성원 간 신뢰에 대한 합의가 끝난 데이터이다

따라서 기존 검증과 달리, 신뢰성을 위한 별도의 기능을 고려하지 않고 저장된 데이터를 바탕으로 검증가능

신원인증을 위해 제출하는 ID에 새로운 속성을 추가하거나 민감한 정보를 삭제해 제출 가능

Verifiable Credential 이라는 보관용 ID와,

Verifiable Presentation 이라는 제출용 ID가 따로 존재한다

보관용 ID는 신분증, 졸업 증명서와 같이 각 기관에서 발급하는 전자 증명서

사용자는 보관용 ID의 속성 중 필요한 부분만 추출하여 제출용 ID를 생성한 뒤 제출할 수 있다

SSI 플랫폼에서 사용하는 ID

또한 영지식 증명 기술을 사용한다면, 검증자에게 ID속성 값을 알려주지 않고도 ID 속성을 검증할 수 있다

SSI에서 사용되는 ID는 모두 전자기기에 암호화되어 안전하게 저장돼서 사용된다

기존의 중앙화된 CA 중심의 구조 대신 SSI 기술의 DID (탈중앙식별자)를 사용하면,

탈중앙화된 구조에서 안전하게 공개키를 교환할 수 있다

SSI 구성요소

SSI 플랫폼의 구성요소

식별자와,

인증수단으로 사용되는 DID 및 DID doc,

보관용 ID로 사용되는 VC(검증가능한 자격증명),

제출용 ID로 사용되는 VP(검증 가능한 제공 ID 데이터 집합) 으로 이루어져 있다

SSI 플랫폼의 주요 참여자

VC를 발행하는 발행인(issuer),

VC를 발급받은 후 VP로 가공하여 검증기관에 제출하는 사용자 (holder),

사용자로부터 VP를 수신하여 VP의 진위를 검증하는 검증인(verifier),

그리고 DID 및 ID 관련 정보를 저장하는 분산 저장소인 블록체인이 있다

분산 저장소는 꼭 블록체인을 사용하지 않아도 되지만,

현재 SSI의 기술적 요구 조건을 수용하기에 가장 적절한 수단이다

VC | VP

보관용 ID로 사용된다

사용자가 발행기관으로부터 발급받은 신분증, 졸업증명서, 재직증명서 등과 같은 신원증명 의미

사용자는 VC를 직접 사용하지 않고, 제출용 ID인 VP로 필요한 속성만 추출 가공해서 사용한다

DID

VC와 VP에 들어가는 식별자

VC와 VP에는 사용자와 발행기관의 DID가 명시된다

따라서 VP를 수신한 검증기관은 VP를 올바른 사용자로부터 수신했는지

VP 제출자 DID를 통해 알 수 있다

VP내 포함된 VC속성을 가진 사람이 사용자가 맞는지는

VC 내 명시된 subject(사용자) DID를 통해 알 수 있다

VP내 포함된 VC속성 값이 어떤 발행기관에서 발행 됐는지는

발행기관의 DID을 통해 알 수 있다

검증기관은 VP내 포함된 VC속성의 ubject(사용자) DID가 진짜 사용자의 것인지

DID Auth를 통해 알 수 있다

블록체인에 저장되는 데이터는 누구나 열람하고 획득할 수 있는 데이터이기 때문에

SSI 플랫폼을 설계할 때는 DID 관련 정보 외에 어떤 데이터가 블록체인에 저장될지 신중하게 결정해야 한다

[블록체인이론] 이더리움 데이터 계층 : 어카운트 구조와 생성

parallelworlds — Wed, 30 Mar 2022 04:42:34 +0900

이더리움 플랫폼 데이터 계층 : 어카운트

이더리움 플랫폼에서 어카운트는 모든 트랜잭션의 실행 주체이자 기본 단위로서 모든 것은 어카운트에서 시작한다

이더리움은 두 가지 어카운트 타입을 갖는다

어카운트

외부소유 어카운트 EOA

일반적으로 말하는 이더리움 사용자 어카운트

사람이 직접 개인키로 관리

스마트 컨트랙트 실행 코드를 가지고 있지 않다

개인 키를 분실하면 해당 어카운트도 분실한 것과 마찬가지이다

EOA는 개인 키를 사용하여 전자 서명된 트랜잭션을 생성 및 실행함으로써

다른 EOA나 컨트랙트 어카운트에 메시지를 보낸다

보통, EOA 간의 메시지는 이더를 전송하는 것

또는 EOA가 컨트랙트 어카운트에 메시지를 보내 해당 코드를 실행시켜 다양한 결과를 만들 수 있다

컨트랙트 어카운트 CA

일반적으로 말하는 스마트 컨트랙트

컨트랙트 어카운트는 외부 소유 어카운트나 다른 컨트랙트 어카운트의 메시지를 받은 후

내부의 스마트 컨트랙트 코드를 실행한 후,

새로운 컨트랙트를 생성하거나 다른 메시지를 읽거나 보낸다

또한, 필요하면 내부 저장 공간에 데이터를 저장할 수도 있다

그러나 랜덤 넘버를 생성하거나 직접 운영체제를 조작하는 API를 호출하는 작업 등은 할 수 없다

오직 EOA나 다른 컨트랙트 보드에 의해서만 작동된다

즉 자기 자신이 직접 새로운 트랜잭션을 실행할 수는 없다

외부 소유 어카운트와 컨트랙트 어카운트

어카운트 구조

type Account struct {
	Nonce	uint64
    Balance	*big.Int
    Root	common.Hash
    CodeHash	[]byte //머클 패트리시아 트리의 루트 해시
}

어카운트 정보는 4개의 필드로 구성되어 있다

넌스

해당 어카운트로부터 보내진 트랜잭션의 수를 의미

0으로 시작한다

트랜잭션을 오직 한 번만 실행되게 할 때 사용할 수 있는 카운터

만약 컨트랙트 어카운트이면 넌스는 어카운트에 의해 생성된 컨트랙트 수다

잔액

해당 어카운트의 이더 잔고

루트

해당 어카운트가 저장될 머클 패트리시아 트리의 루트 노드

참고로, 실제 어카운트의 저장소는 머클 패트리시아 트리에 저장된다

이 트리의 루트 노드를 암호 해시한 것이 바로 루트

암호 해시는 Keccak256 암호 해시를 사용한다

코드해시

해당 어카운트의 스마트 컨트랙트 바이트 코드의 해시

코드 해시값이 비어 있으면 해당 어카운트는 EOA이다

어카운트 생성

모든 이더리움 어카운트는 개인 키와 공개 키의 쌍으로 정의된다

개인 키와 공개 키를 비대칭 키라고 한다

이더리움은 비대칭 암호화 알고리즘으로 256비트 ECDSA를 사용한다

이더리움은 C언어로 작성된 비트코인의 ECDSA 라이브러리인 secp256k1을 GO언어로 래핑하여 사용한다

ECDSA 서명 암호화를 통해 얻은 256비트 공개 키를

다시 암호 해시 알고리즘 Keccak256을 사용하여 암호화하여 32바이트의 고정값을 생성하고

이 중 20바이트를 절삭하여 어카운트 주솟값으로 사용한다

ECDSA : 비대칭 암호 키의 생성 알고리즘

Keccak256 : 임의의 값을 암호화 한 후 고정 크기 값을 생성해 내는 암호 해시 함수

>> 어카운트 주소 = Keccak256(공개키(ECDSA(개인키)))

어카운트 주소생성

Account 패키지 : 어카운트 생성

일반적으로 말하는 이더리움 사용자 어카운트

사람이 직접 개인키로 관리

코드분석

2022.03.30 - [텃밭 1 : BlockChain/Go] - [Go] 이더리움 Account 패키지 : 어카운트 생성 코드 분석

[Go] 이더리움 Account 패키지 : 어카운트 생성 코드 분석

이더리움 Account 패키지 : 어카운트 생성 코드 분석 GitHub - potterpeter/core-ethereum-book-code-review: core ethereum book code review core ethereum book code review. Contribute to potterpete..

1parallelworlds.tistory.com

어카운트 상태

어카운트들이 모인 것을 이더리움에서는 상태라고 하고

이를 stateObject 구조체로 표현한다

어카운트에 접근하여 상태를 변경하려면 stateObject를 통해 접근한 후 상태를 변경할 수 있다

변경된 어카운트는 CommitTrie() 함수를 호출하여

변경된 Trie를 ethdb 패키지를 통해 levelDB에 업데이트한다

//go-ethereum/core/state/state_object.go / 66

type stateObject struct {
	address  common.Address
	addrHash common.Hash // hash of ethereum address of the account
	data     types.StateAccount
	db       *StateDB

	// DB error.
	// State objects are used by the consensus core and VM which are
	// unable to deal with database-level errors. Any error that occurs
	// during a database read is memoized here and will eventually be returned
	// by StateDB.Commit.
	dbErr error

	// Write caches.
	trie Trie // storage trie, which becomes non-nil on first access
	code Code // contract bytecode, which gets set when code is loaded

	originStorage  Storage // Storage cache of original entries to dedup rewrites, reset for every transaction
	pendingStorage Storage // Storage entries that need to be flushed to disk, at the end of an entire block
	dirtyStorage   Storage // Storage entries that have been modified in the current transaction execution
	fakeStorage    Storage // Fake storage which constructed by caller for debugging purpose.

	// Cache flags.
	// When an object is marked suicided it will be delete from the trie
	// during the "update" phase of the state transition.
	dirtyCode bool // true if the code was updated
	suicided  bool
	deleted   bool
}