WebAuthn 스펙은 FIDO 스펙이 진화한 결과입니다.

애플, 구글, MS 등의 업체들이 지지하고 있으며 "패스키(Passkey)"라는 브랜드 네임으로 알려져 있습니다.

WebAuthn 스펙을 정말 잘 설명하고 있는 글이 있어 일부를 번역하여 공유합니다.

그냥 "좋은 글이 있어요"라고 링크만 소개하고 말기에는 아깝다는 생각이 들었습니다.

글의 출처는 https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html 입니다.

 

패스워드는 쓰레기입니다

패스워드는 쓰레기입니다. 이 글을 읽는 분이라면 이미 이 생각에 동의하시겠지만, 왜 그런지 다시 한 번 살펴 봅시다.

 

사람들은 보통, 패스워드 몇 개를 여기저기 돌려씁니다.

(랜덤하게 패스워드를 만들어내는 패스워드 매니저라는 도구가 있지만, 사람들이 쓰지 않지요.) 웹사이트는 패스워드의 해시값을 저장하고, 인증할 때 이 해시값을 사용합니다. 그런데 대부분의 패스워드는 엔트로피가 낮아서, 해시값만 유출돼도 무차별 대입 공격에 의해 노출됩니다. (haveibeenpwned.com 사이트에 의하면 대략 800 개 웹사이트에서 135억 개 계정이 유출됐다고 합니다.)

 

패스워드 데이터베이스가 유출되면, 패스워드가 유출된 그 웹사이트만 문제가 되는 게 아닙니다. 패스워드를 여러 곳에서 돌려쓰는 행태 때문에, 다른 웹사이트들도 문제가 됩니다.

 

다음으로, 패스워드는 사람이 기억하기 때문에, 비슷해 보이는 웹사이트로 사람을 속여서 패스워드를 입력하게 할 수 있습니다. 이러한 "피싱(phishing)" 공격은 흔하고 효과적입니다.

 

마지막으로, 패스워드는 소프트웨어 계층 여기저기서 유출될 수 있습니다. 거대 기업 페이스북조차 수억 개의 패스워드를 실수로 로깅(logging)한 적이 있습니다. 그리고 자바스크립트 인젝션 공격은 패스워드를 포함해서 웹사이트에 입력하는 모든 내용을 유출시킬 수 있습니다.

 

더 나은 인증(AuthN)에 관한 이야기

이 글은 공개키 서명 체계(public key signature scheme)를 사용해서 더 나은 인증(authentication) 시스템을 만들려는 노력에 관한 이야기입니다. 공개키 서명은 ECDSA, RSA, ML-DSA 등으로 불립니다. 이는 결과값이 얼마나 큰지, 결과값을 얻는 데 얼마나 오래 걸리는지, (아직 이론적인 이야기지만) 양자 컴퓨터 내성을 얼마나 갖고 있는지에 따른 분류입니다.

 

공개키 서명 체계는 세 가지 연산을 제공합니다.

  1. `generate` 연산은 난수 비트를 받아서 공개키와 개인키라고 불리는 두 개의 바이트 문자열을 반환하는 작업입니다.
  2. `sign` 연산은 개인키와 임의의 바이트 문자열(메시지라고 함)을 받아서 "서명(signature)"이라고 불리는 또 다른 바이트 문자열을 생성하는 작업입니다.
  3. `verify` 연산은 공개키, 메시지, 서명 값을 받아서 해당 서명이 해당 개인키를 사용해서 생성됐는지 검증하는 작업입니다.

공개키 서명 체계가 유용하려면 다음과 같은 속성이 있어야 합니다.

  1. 공개키로부터 개인키를 계산하는 것은 불가능해야 합니다.
  2. 개인키 없이는 서명을 계산할 수 없어야 합니다.

 

공개키 서명을 사용한 인증(AuthN) 방식

다음은 공개키 서명을 사용한 인증(authentication) 방식의 간단히 예입니다.

 

사용자는 username과 password를 만들어 웹사이트에 등록하지 않습니다. 대신 사용자는 웹사이트에 등록하기 위해 usrename을 만든 다음 사용자의 컴퓨터에서 generate 연산을 실행해서 key pair(공개키와 개인키)를 만듭니다. 그리고 사용자의 컴퓨터에 개인키를 저장한 다음, 공개키와 username을 웹사이트에 제출합니다.

 

로그인할 때 사용자는 username을 입력합니다. 그러면 사용자의 컴퓨터가 사용자의 개인키를 사용해서 "let me in" 메시지에 대해 서명 값을 계산합니다. 그리고 username과 서명 값을 웹사이트로 전송합니다. 마지막으로 웹사이트는 사용자가 가입할 때 등록한 공개키를 사용해서 "let me in" 메시지와 제출된 서명을 검증합니다. 서명이 유효하다면 사용자는 로그인됩니다.

 

우리는 방금 데이터베이스 유출 문제를 해결했습니다.

이제 웹사이트는 패스워드 해시 대신 공개키를 저장하면 됩니다. 공개키는 서명을 생성하는 데 사용할 수 없고, 오직 서명을 검증하는 데만 사용됩니다. 따라서 패스워드와 달리, 공개키는 유출되더라도 이를 이용해서 해당 웹사이트나 다른 웹사이트에 로그인할 수 없습니다.

 

피싱 문제가 남았습니다

하지만 피싱(phishing) 문제가 남았습니다. 사람들은 여전히 가짜 웹사이트에 서명 값을 제출할 수 있습니다. 사용자의 서명 값을 알아낸 공격자는 이를 사용해서 해당 사용자인 것처럼 진짜 웹사이트에 로그인할 수 있습니다.

 

피싱 문제를 해결해 봅시다.

 

피싱은 공격자가 사용자의 로그인 정보를 갈취하는 수법입니다. 피해자가 실수로 가짜 웹사이트에 로그인하면, 공격자는 그 정보를 실제 웹사이트에서 재사용합니다. 앞에서 소개한 로그인 방식은 모든 웹사이트가 "let me in"이라는 동일한 메시지를 사용해서 서명을 만들었기 때문에 피싱에 취약했습니다.

 

설계를 수정해 봅시다.

첫 번째로 할 일은 서명할 메시지를 바꾸는 것입니다. 서명할 메시지에 로그인할 웹사이트의 이름을 넣어 봅시다. 그리고 메시지를 JSON 형태로 바꿔 봅시다.

 

사용자가 로그인할 때 사용자의 컴퓨터는 사용자의 개인키를 사용해서 서명 작업을 실행합니다. 하지만 이제 "let me in" 메시지 대신 {"origin": "https://example.com"} 메시지를 사용합니다. 웹사이트는 생성된 서명에 대해 검증 작업을 실행해야 합니다. 검증 작업에는 메시지 입력이 필요하므로 사용자의 컴퓨터에서 서명 및 username과 함께 메시지를 전송하도록 합시다.

 

이제 사용자가 악성 링크를 클릭해서 exampl3.com(악의적인 피싱 웹사이트)에 로그인을 시도할 때 어떤 일이 일어나는지 생각해 봅시다. 사용자의 컴퓨터는 {"origin": "https://exampl3.com"}이라는 메시지에 서명합니다. 피싱 사이트가 이 서명을 갈취해서 진짜 웹사이트에 전달하면 진짜 웹사이트는 사용자의 서명이 다름(다른 origin를 기초로 만들어진 것임)을 인식하고 로그인을 거부합니다. (컴퓨터는 사람과 달라서 URL에서 문자 하나만 바뀌어도 확실하게 감지할 수 있습니다.)

 

피싱 사이트는 메시지를 바꿀 수 없습니다. 메시지를 바꾸더라도 사용자의 개인키가 없기 때문에 유효한 서명을 새로 만들 수 없습니다.

 

서명 값 유출 문제가 남았습니다

이제 피싱 사이트 문제는 해결됐습니다. 하지만, 진짜 웹사이트에서 서명 값이 유출됐을 경우 유출된 서명 값이 사용자 로그인에 사용될 수 있다는 문제는 여전히 남아 있습니다. 패스워드 해시와 달리 서명 값은 저장할 필요가 없습니다. 하지만, 자바스크립트 인젝션 및 부주의한 로깅을 통해 서명 값이 유출될 위험은 있습니다.

 

우리는 피싱 사이트 문제 해결하기 위해 사이트마다 고유한 메시지를 사용했습니다. 이제 서명 값 유출 문제를 해결하기 위해 인증(authentication) 시도마다 고유한 메시지를 사용해 봅시다.

 

두 번째로 할 일은 사용자가 로그인을 시도할 때마다 서명할 메시지를 바꾸는 것입니다.

사용자가 로그인을 시도할 때마다 웹사이트에서 랜덤 챌런지(random challenge) 문자열을 전송해서 서명하게 합시다. 사용자가 로그인을 시도할 때마다 랜덤 챌런지 문자열이 바뀌도록 합시다.

 

이제 서명할 메시지는 다음과 같습니다. 

{"origin": "https://example.com", "challenge": "8065afbaa4faee78123ad2061bc78df3"}.

 

이제 악성 JavaScript나 부주의한 로깅에 때문에 서명 값이 유출되더라도, 그 서명 값은 그 즉시 쓸모를 잃습니다. 인증(authentication)할 때마다 서명할 메시지가 달라지기 때문입니다.

 

전용 하드웨어를 이용하면 보안성이 극대화됩니다

여전히 개인이 얼마나 많은 공개키를 갖게 할지, 그리고 그 공개키를 어디에 저장하게 할지 고민해야 합니다.

 

간단한 답은 한 사람이 하나의 공개 키를 갖고 모든 웹사이트와 앱에서 사용하는 것입니다. 하지만 이 방법은 명백한 문제가 있는데, 그 공개키가 그 사람에 대한 고유한 추적 값이 된다는 점입니다. 사람들은 웹사이트나 앱에서 추적되는 것을 원치 않습니다.

 

지금은 각 웹사이트나 앱이 저마다의 암호키 목록을 갖는다고 가정하겠습니다. 실제로는 이보다 더 복잡하지만, 이후 장에서 자세히 다루겠습니다.

 

패스워드와 달리 개인키는 사용 중 어디에도 전송되지 않습니다. 편의를 위해 전용 하드웨어(보통 USB로 연결)를 이용해서 개인키를 생성하고 보관한다고 가정하겠습니다. 이렇게 하면 보안성이 극대화됩니다. 개인키를 생성하고 보관하는 이런 하드웨어는 어느 정도의 물리적 공격에도 버티도록 설계돼 있습니다.

 

더 나은 인증(AuthN) 시스템

인증(authentication) 시스템의 어쩔 수 없는 한계도 생각해야 합니다.

 

디지털 환경에서 사람들은 항상 컴퓨터를 통해 행동합니다. 사용자 인증(authentication)을 말할 때, 인증을 통해 직접적으로 권한을 얻는 것은 해당 사용자의 컴퓨터입니다. 따라서 해당 컴퓨터가 공격자에 의해 제어된다면 인증 시스템은 무의미해집니다. 인증 문제를 해결한다고 모든 보안 문제가 해결되는 것이 아닙니다. 하지만, 많은 보안 문제가 인증 문제와 관련돼 있습니다. 그렇기 때문에 세상을 바로잡기 위해서는 더 나은 인증 시스템이 필요합니다.

 

이 글의 주제인 WebAuthn이 바로 그런 시스템입니다.

 

패스키는 안전합니다.
패스워드 방식과 달리 기밀한 정보(private key)가 절대 서버로 전달되지 않습니다.


패스키는 사용하기 쉽습니다.
지금도 애플, 구글, MS 등 플랫폼 업체들이 패스키 사용에 필요한 화면을 한 단계라도 더 줄이기 위해 (사용자 편의성을 높이기 위해) 애쓰고 있습니다.


패스키는 표준입니다.
어느 누구도 패스키 기술을 독점할 수 없도록 W3C가 WebAuthn 스펙을 관리합니다.


자신있게 적극적으로 패스키를 사용해서 디지털 일상생활을 보다 더 안전하게 만드시기 바랍니다.

Posted by ingeeC
,

안드로이드 TDD 요약

Dev 2025. 2. 21. 16:22

안드로이드 앱을 개발하게 됐습니다.
할 일은 많고 일손은 부족합니다. 무심코 개발을 진행하다 삐끗하면 버그 잡느라 많은 시간을 소진할 것 같습니다. 그래서 웹앱 개발할 때 도움됐던 TDD를 안드로이드 앱 개발에도 적용해보기로 합니다.

관련 내용을 요약합니다. 과제가 마무리되면 소감도 올려보겠습니다.

 

개요

  • 안드로이드는 앱 테스트 자동화를 위해 JUnit(Test Runner)을 사용한다
  • 안드로이드 앱 프로젝트를 생성하면 유닛 테스트(Unit Test)와 기기 테스트(Instrumentation Test) 환경이 자동 생성된다
    • Unit Test: app/src/test 디렉토리의 test 프로젝트
    • Instrumentation Test: app/src/androidTest 디렉토리의 androidTest 프로젝트

 

상세

  • 주로 ViewModel 클래스가 안드로이드 Unit Test의 대상이다
  • JUnit에서 사용하는 주요 어노테이션은 다음과 같다
    • @Before, @After, @Test, @Ignore, ...
  • 테스트 피라미드

 

TDD 관점 상세

  • 테스트 코드를 (구현 코드보다) 먼저 작성해야 TDD다
  • TDD의 효과
    • 테스트 코드가 프로젝트에 대한 최신의(up-to-date한) 문서 역할을 한다
    • 확신을 갖고 개발할 수 있다 (코드 수정으로 인해 깨지는 기능이 없음을 확신할 수 있다)
  • 테스트 피라미드
    • (최상위) End-to-end Test : Appium, Calaba.sh 사용 (둘 다 Selenium 기반 도구)
    • (중간) Integration Test : mockServer with OkHttp 사용
    • (최하위) Unit Test : JUnit, Robolectric, Espresso 사용

테스트 피라미드

  • 다음과 같은 경우 Unit Test가 아니다
    • DB를 호출하는 경우
    • 네트워크를 이용하는 경우
    • 파일 시스템을 건드리는 경우
    • 다른 유닛 테스트와 동시에 실행할 수 없는 경우
    • 테스트 실행을 위해 (환경 변수 설정 같은) 특별한 작업이 필요한 경우

 

테스트 프레임워크 Robolectric

  • app/src/test 디렉토리에 위치하는 Unit Test 작성에 적합하다 (실행 속도가 빠르고 안드로이드 view의 라이프사이클을 테스트할 수 있다)
  • 테스트 코드 샘플 : 버튼을 클릭하면 inputText에 입력한 문자열을 label에 표시
@Test 
public void shouIdDispIayTextFromEditTextOnTextField_whenClickOnChangeHelloWorldButton() throws Exception { 
  EditText inputText = (EditText) mainActivity.findViewById(R.id.label_input);
  inputText.setText("This app is fun!"); 
  changeHelloWorldTextButton.performClick();
  assertThat(helloWordLabel).hasText("This app is fun!");
}

 

테스트 프레임워크 Espresso

  • app/src/androidTest 디렉토리에 위치하는 기기 테스트(instrumentation test: 실제 기기 또는 에뮬레이터에서 실행되는 테스트) 작성에 적합하다
  • Espresso 테스트는 실행 시간이 오래 걸린다 (그래서 빠른 피드백이 필수인 TDD에 적합하지 않다)
  • Unit Test보다 End-to-end Test에 가깝게 쓰는 게 좋다

 

결론 (이렇게 해보기로 했다)

  • app/src/test 디렉토리의 test 프로젝트에서 Roboletric을 이용해서 Unit Test를 작성하면서 TDD를 시도한다
  • 통합 테스트는 필요할 경우(Unit Test 보다 적게), app/src/androidTest 디렉토리의 androidTest 프로젝트에서 Espresso를 이용해서 작성한다
  • e2e 테스트는 정말 필요성할 때만, Appium을 이용해서 작성한다

 

후기

  • 안드로이드 테스트 자동화 관련 최신 자료가 별로 없었다
  • 테스트 도구 자체는 오랫동안 변화가 없었던 듯하다

 

Ref.

Posted by ingeeC
,

들어가며.
UCAN은 웹3 세상을 위한 Authorization(이후 AuthZ) 기술 입니다.
DID를 이용해서, DID document가 제공하는 pub-key를 인증 수단으로 사용하자는 아이디어가 핵심입니다.

 

웹3를 위한 Access Token, UCAN

 

개요

  • UCAN은 User Controlled AuthZ Network의 약자 (본질은 Access Token)
  • 사용자 데이터의 통제권을 사용자 개인에게 부여하는 기술
  • UCAN의 특징
    • Trustless: UCAN 토큰의 유통 및 권한 행사에 참여하는 누구도 신뢰를 강요하지 않는다 (Trustless한 객체들이 모여 신뢰할 수 있는 결과를 만든다)
    • Secure: 암호 알고리즘이 안전을 보장한다
    • 그리고, local-first, user-originated 하다

 

상세

  • 아이디어의 배경: 탈중앙화된 웹3 환경에서는 기존과 다른 AuthZ 방식을 고민해야 한다
    • ACL을 관리하는 '중앙'이 없기 때문이다
    • AuthZ 관리에 필요한 모든 내용을 포함한 토큰을 이용하면 탈중앙화된 방식으로 권한 관리를 수행할 수 있다 (UCAN은 SPKI와 OCAP/object capability 기술을 참조했다)
  • UCAN 토큰은 영화티켓에 비유할 수 있다
    • 누구도 당신의 신원/Identity을 묻지 않는다
    • 다른 사람에게 티켓을 양도할 수 있다 (이를 위해 극장과 협의할 필요도 없다)
  • UCAN은 자원, 권한, 주체를 명시하기 위해 DID를 사용한다
    • UCAN 규격은 다음 예시와 같다 (Payload 스펙 참조)
      {
        `header`: {
          `alg`: Algorithm, // the type of signature.
          `typ`: Type, // the type of this data structure, JWT.
          `uav`: UCAN version.
        },
        `payload`: {
          `iss`: DID, // Required. Issuer DID (sender)
          `aud`: DID, // Required. Audience DID (receiver)
          `sub`: DID, // Required. Principal that the chain is about (the [Subject])
          `cmd`: String, // Required. The [Command] to eventually invoke
          `args`: {String : Any}, // Required. Any [Arguments] for the Invocation
          `nonce`: Bytes, // Required. Nonce
          `meta`: {String : Any}, // Not Required. [Meta] (asserted, signed data)
          `nbf`: Integer, // Not Required. "Not before" UTC Unix Timestamp
          `exp`: Integer | Null, // Required. Expiration UTC Unix Timestamp
        },
        `signature`: Bytes // A signature (using alg) of the base64 encoded header and payload concatenated together and delimited by '.'
      }
  • UCAN으로 할 수 있는 일
    • Delegation/위임: 권한을 발급, 전달, 제한한다
    • Invocation/사용: 위임된 권한을 행사한다
    • Revocation/철회: UCAN 토큰에 명시된 권한을 철회한다
  • UCAN 토큰 발급과 검증을 위한 다수의 라이브러리가 존재한다

 

Ref.

 

요약.
UCAN은 DID를 기반으로 정의한 탈중앙화 Web3 시대를 위한 억세스 토큰(AuthZ 토큰)입니다.
UCAN이 동작하려면 DID 인프라가 갖춰져 있어야 합니다.

Posted by ingeeC
,

DID-Core 스펙을 요약합니다.
DID-Core 스펙은 2022년 표준화 완료되었습니다 (W3C Recommendation 19 July 2022).
DID는 웹3 세계의 기초를 이루는 기반 기술입니다.

 

Web3를 위한 ID, DID

DID는 `Scheme + DID Method + DID Method-specific ID`로 구성된 문자열이다

  • 예시) did:example:123456789abcdefghi

 

DID는 개념이자 인프라다

  • Key-pair의 유통과 검증을 위해 PKI(인프라)가 존재하는 것처럼, DID와 DID document의 유통과 검증을 위해 DID 인프라가 필요하다
  • 어떤 DID가 있으면 이에 대한 DID document를 가져올 수 있다 (DID Resolution)
  • DID document를 어떻게 저장하고 검색해서 가져오는지는 스펙 범위 밖이다 (마음대로 구현해도 좋다)
  • DID document에는 pub-key 같은 증명수단(verification method)들이 담겨있다 
# DID document 샘플
{
"@context": [
  "https://www.w3.org/ns/did/v1",
  "https://w3id.org/security/suites/ed25519-2020/v1"
]
"id": "did:example:123456789abcdefghi",
"authentication": [{
  "id": "did:example:123456789abcdefghi#keys-1",
  "type": "Ed25519VerificationKey2020",
  "controller": "did:example:123456789abcdefghi",
  "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}]
}

 

DID method가 DID Resolution 방식을 결정한다

  • DID method에 따라 어떤 종류의 DID는 생성하면 끝이다 (더 이상의 추가 절차가 필요 없다)
  • 어떤 종류의 DID는 생성후 verifiable data registry에 등록하는 절차가 필요하다
  • 다양한 DID method 목록이 DID Methods 목록 문서에 정리되어 있다 (비트코인 기반의 btcr, 이더리움 기반의 ethr, IPFS 기반의 ipid를 눈여겨볼 만하다)

 

결론
요약하자면, DID는 ID로 document를 조회할 수 있는 ID체계입니다.

 

Posted by ingeeC
,

웹브라우저 기반 IPFS 네트워크에 관심이 많습니다.
웹브라우저만으로 IPFS 네트워크를 구축할 수 있다면, 서버 없는 서비스(웹3 서비스)가 가능해집니다.
IPFS 블로그(https://blog.ipfs.tech/)에서 이와 관련된 기사를 골라 요약합니다.

The State of Dapps on IPFS: Trust vs. Verification

https://blog.ipfs.tech/dapps-ipfs/
2024-01-29

  • SPA 또는 MPA 형태로 개발된 Dapp은 IPFS로 쉽게 배포할 수 있다
  • Helia는 브라우저를 IPFS 노드로 만들어주는 라이브러리다
  • Helia가 브라우저에서 제공하는 기능은 'CID 데이터 관리'와 'CID 데이터에 대한 Verified Retrieval' 2가지다
    • CID 데이터 관리: 데이터를 CID 데이터로 만들고 해석하는 기능을 제공한다
    • CID 데이터에 대한 Verified Retrieval: CID로 지정된 데이터를 Bitswap 또는 IPFS Gateway를 통해 가져올 수 있다
    • 브라우저 IPFS 노드는 보통 수명주기가 짧기 때문에, CID 데이터를 업로드할 때는 1) pinning 서비스를 이용하거나, 2)직접 운영하는 IPFS 노드(서버)를 이용하는 것이 좋다

 

Verified IPFS Retrieval in Browsers with @helia/verified-fetch

https://blog.ipfs.tech/verified-fetch/
2024-04-18

  • IPFS Gateway는 브라우저에서 IPFS 데이터를 가져올 때 특히 유용한 기술이다
  • IPFS 데이터에 대한 검증(Verification: IPFS Gateway가 전송한 데이터가 내가 요구한 그 데이터가 맞는가에 대한 검증)을 브라우저가 수행한다면, 브라우저는 IPFS Gateway를 신뢰하지 않더라도 문제 없이 이용할 수 있다 (Trustless Gateway 사용이 가능하다)
  • 이를 위해 Interplanetary Shipyard팀(프로토콜랩으로부터 분사한 개발조직)이 @helia/verified-fetch 라이브러리를 개발/배포한다
  • Shipyard팀의 다음 목표는 WebRTC와 WebTransport 프로토콜을 이용해서 브라우저에서 직접 Kubo IPFS 노드와 통신하는 것이다

 

IPFS on the Web in 2024: Update From Interplanetary Shipyard

https://blog.ipfs.tech/2024-shipyard-improving-ipfs-on-the-web/
2024-11-25

  • 우리(Interplanetary Shipyard)가 관심을 갖는 주제는 웹에서 IPFS를 사용하는 것이다
  • 다시 말해 웹브라우저에서 다른 IPFS 노드에 연결할 수 있게 만드는 것이다
  • 이를 위해 다음과 같은 프로젝트를 진행하고 있다
    • Verified Fetch: 브라우저의 fetch API와 유사한 API를 제공, 이를 통해 IPFS 데이터를 검증/수신하는 기능을 제공한다
    • Browser Transport: 브라우저에서 사용할 수 있는 WebRTC와 WebTransport 프로토콜을 기반으로 외부 IPFS 노드와 통신하는 기능을 제공한다
    • AutoTLS: 브라우저는 보안 통신을 위해 CA 공인 인증서를 요구하나 IPFS 노드는 통상 인증서 없이 운영된다. AutoTLS는 이 갭을 메꾸는 기능을 한다
    • Delegated Routing: 브라우저가 IPFS 기능을 호출할 때 이용할 수 있는 https://delegated-ipfs.dev/routing/v1 엔드포인트를 프로토콜랩이 운영/제공한다

 

Browser P2P Connectivity with WebRTC and js-libp2p

https://docs.libp2p.io/guides/getting-started/webrtc/
2024-06-12

  • 브라우저 p2p 커넥션을 만들려면 서버의 지원이 필요하다
    • STUN: 브라우저 노드의 public ip를 알아내기 위해 필요하다
    • TURN: 공개 IP가 부여된 서버가 브라우저-to-브라우저 통신을 중계한다 (서버 비용이 든다. 이 글에서는 TURN 서버 대신 GossipSub 프로토콜 이용을 추천한다)
    • Signaling: libp2p의 WebRTC 통신 초기 연결을 위해서 필요하다
    • Libp2p relay: 브라우저 노드도 PubSub 프로토콜(GossipSub)을 이용하면 서로 연결될 수 있다 (데모 용도로는 좋으나 배틀 테스트를 거치지 않아서 제품 용도로는 신뢰할 수 없다)
  • GossipSub 프로토콜을 이용한 브라우저 간 libp2p 통신 수립 가이드 (실제 동작하는 데모, 강추!)
    • 스텝1: 소스레포 복사 및 라이브러리 설치
    • 스텝2: js-libp2p node.js relay 실행
    • 스텝3: 브라우저에서 js-libp2p 실행
    • 스텝4: 브라우저에서 relay로 연결
    • 스텝5: Circuit Relay를 이용, 브라우저를 dialable하게 만들기
    • 스텝6: relay를 브라우저 앱의 부트스트랩 피어로 설정
    • 스텝7: WebRTC를 listen하여 direct connection 만들기
    • 스텝8: PubSub 피어 찾기

 

결론
1)인푸라 등에서 제공하는 무료 IPFS 노드와 2)Helia 라이브러리와 3)PubSub(GossipSub) 프로토콜을 이용하면 비용 없이 브라우저-to-브라우저 IPFS 네트워크를 구축하는 것이 가능합니다.
다시 말해, 비용 없이 웹3 서비스를 실현할 수 있습니다. 이제 필요한 건 당신의 상상력입니다.

Posted by ingeeC
,