본문 바로가기
Coding

Web 3.0에 대한 Web 2.0 개발자 가이드

by 건강하고부유한습관 2022. 5. 14.
반응형

Web 3.0에 대한 Web 2.0 개발자 가이드

 

블록체인과 Web 3.0이 백엔드 소프트웨어 개발의 다음 반복을 어떻게 형성할 수 있는지 알아보십시오.

https://youteam.io/blog/wp-content/uploads/2018/04/image-e1523955910900.png를 통한 크리에이티브 커먼즈

지난 몇 년 동안 저는 다음과 같은 진술로 제 엔지니어링 배경을 활용하려고 노력했습니다.

"당신이 투자하는 것들이 어떻게 작동하는지 배우고 당신이 알고 있는 것에 투자하십시오."

이로 인해 내가 핵심적으로 알고 있던 기술에 대한 확신이 높은 투자가 이루어졌습니다. 마찬가지로 처음에는 맹목적으로 투자한 기술에 대해 배우려고 노력했습니다. 결국 저는 암호화폐가 핵심에서 어떻게 작동하는지 배우기로 결정했을 때 가장 위대한 학습 여정 중 하나로 이끌렸습니다. 레이어 1(이더리움, 비트코인 ​​등) 백서를 공부한 후, 솔리디티 학습을 통해 "스마트 계약"의 개념을 마스터하는 것이 가장 빠르게 참여할 수 있다는 것을 깨달았습니다.

소프트웨어 엔지니어링에 대한 제 배경 지식은 문법 학습을 매우 쉽게 만들었습니다. 이 훌륭한 과정과 약간의 재무 지식 덕분에 저는 그 어느 때보다 많은 관심을 불러일으키는 새로운 학문 분야를 발견했습니다.

스마트 계약을 작성하고 웹 3.0 생태계와 상호 작용하기 시작했을 때, 저는 서비스의 합리화와 이 멋진 신세계의 협업적 특성에 빠르게 매료되었습니다. 웹 2.0 API, OOP, 호스팅 및 표준화가 보편적인 기술로 통합된 덩어리를 보았을 때 통화와 금융이 주요 사용 사례라는 사실을 잊었습니다.

주요 내용: 블록체인은 화폐 그 이상입니다. 그것은 인터넷에서 구축의 다음 반복입니다. 이 기사에서 나는 초보자를 위한 몇 가지 용어를 제공하고 다른 기술자가 이 기술의 잠재력을 볼 수 있도록 웹 2.0 언어에서 유사점을 그리는 것을 목표로 합니다.

이 제목의 용어를 이해하는 것이 블록체인을 이해하기 시작하는 기본 단계입니다. 이러한 정의는 이 문서의 나머지 부분을 몇 가지 간단한 정의로 보완하기 위한 것일 뿐입니다. 따라서 이러한 설명이 모호해 보인다면 독자가 각 정의를 개별적으로 살펴보기를 권장합니다. 이 용어를 알고 있다면 이 섹션 아래의 주요 주제로 건너뛰는 것이 좋습니다!

블록체인 — 상당한 수의 서버 내에서 트랜잭션이 유효하다는 합의가 발견되면 트랜잭션을 통해 액세스할 수 있는 데이터 및 기능 사본을 저장하는 서버 네트워크입니다. 블록체인에는 "가스"의 형태로 컴퓨팅 성능에 대해 이러한 서버 운영자에게 지불하는 자체 고유 통화가 있습니다. 이것이 모든 레이어 1 토큰의 실제 유틸리티인 컴퓨팅 성능에 대한 액세스입니다. 지갑 — 네트워크의 L1 토큰의 일부를 할당/전송할 수 있는 블록체인의 주소, 네트워크의 L1 토큰을 할당/전송할 수 있으며, 주소의 ID로 스마트 계약과 상호 작용하기 위해 트랜잭션에 서명할 수 있습니다. 이것이 다른 L2 토큰을 허용하는 방법).

스마트 계약 — 지갑의 모든 기능을 포함하는 블록체인의 주소(L1 보내기/받기). 상태 변수를 통해 데이터를 저장하고(데이터베이스를 생각), 바이트코드를 통해 기능을 실행하고(데이터베이스/API 기능을 생각), 지갑과 같은 다른 계약과 상호 작용할 수 있습니다.

레이어 2 토큰 — 발행, 전송, 소각 및 기타 통화 기능을 용이하게 하는 공통 기능이 있는 인터페이스(ERC20)를 구현하는 스마트 계약입니다. 지갑은 L1을 보유하는 것과 같은 방식으로 L2 토큰을 "보유"하지 않습니다. 그것은 단순히 토큰을 전송하기 위해 L2 계약과 상호 작용할 수 있으며, 자체 주소와 전송 대상 주소에 대한 잔액 상태 변수를 효과적으로 변경할 수 있습니다.

일반적인 Web 2.0 API의 흐름은 다음과 같습니다.

1. 웹사이트에서 인증키 결제

2. URL 문자열에 페이로드 및/또는 변수를 빌드하기 위한 문자열 처리 코드 작성

3. 언어별 HTTP 라이브러리를 사용하여 get/post 요청 보내기

4. 출력 JSON 구조를 학습한 후 다른 라이브러리를 사용하여 언어 기본 데이터 유형으로 구문 분석

노련한 소프트웨어 엔지니어에게 이것은 위협적인 프로세스가 아니며 이러한 단계만 포함됩니다. 그러나 API 통합은 빈약한 문서, 어려운 출력 데이터 유형, 유료 키 작업, 업그레이드 또는 API 변경으로 인해 지루하고 시간이 많이 소요될 수 있습니다. 개발자는 일부 API가 이해 가능하고 잘 문서화되어 있고 다른 API는 구식이고 투박한 경우에 얻을 수 있는 결과를 결코 알지 못합니다.

Web 3.0에서 데이터는 다음과 같은 많은 문제를 해결하는 다른 방식으로 액세스됩니다.

1. 일부 데이터 또는 서비스를 제공하는 일부 다른 조직 또는 개인에 의해 개발 및 배포된 또 다른 계약은 공용 기능의 인터페이스(라이브러리와 유사)를 게시합니다.

2. 자체 코드에서 인터페이스에 대한 코드를 가져올 수 있습니다. 그런 다음 계약 주소를 알면 해당 인터페이스의 구현이 다음과 같은 주소에서 사용 가능하다는 것을 solidity에 말할 수 있습니다.

IsomeAPI api = IsomeAPI(address);

3. 이제 새 개체를 사용하여 다른 계약과 상호 작용할 수 있습니다. 계약은 또한 내장된 견고성이므로 자체 코드와 외부 계약 모두 기본 입력 및 출력 데이터 유형을 사용합니다. 상호 작용은 마치 객체가 계약에 있는 것처럼 보이고 느껴집니다.

uint temp = api.getTemp(latitude, longitude);

데이터 액세스에 대한 이 새로운 솔루션을 사용하면 개발자에게 필요한 만큼 많은 데이터 소스를 빠르고 능률적으로 통합할 수 있습니다. 오픈 소스 특성을 감안할 때 문서는 여전히 유용하지만 한 Solidity 개발자가 인터페이스 코드를 보고 상호 작용하는 질문에 답할 수 있으므로 더 이상 필요하지 않습니다. 동시에 범용 프로토콜이 등장할 수 있습니다. IERC20은 L2 토큰용 인터페이스/API입니다. 모든 토큰의 주소인 IERC20(address)를 제공하여 개발자는 고유한 토큰에 보편적으로 액세스할 수 있을 뿐만 아니라 몇 분 안에 고유한 토큰을 만들 수 있습니다.

이점은 확장성과 재현성에 그치지 않습니다. L1 및 L2에 내장된 결제 시스템으로 인해 계약/API 개발자는 기능 사용 또는 데이터 액세스에 대해 사용자에게 요금을 부과하는 시스템을 쉽게 내장할 수 있습니다. 즉, API를 사용하는 개발자는 신용 카드, 구독 또는 혼란스러운 가격 모델이 필요하지 않습니다. 어떤 통화를 얼마만큼 보유해야 하는지 이해하기만 하면 되며, 양쪽 모두의 지불은 항상 완벽하게 작동합니다.

마지막으로, 일부는 데이터가 여전히 매우 필요한 Web 2.0 API에 대한 견고성 비호환성으로 인해 이 개념에 이의를 제기할 수 있습니다. 운 좋게도 Chainlink와 같은 이벤트 기반 오라클 알고리즘이 등장했습니다. 이러한 오라클은 타사 API에 액세스하고 이 데이터를 스마트 계약 세계로 푸시하여 본질적으로 Web 2.0 API를 래핑합니다. Web 3.0 세계에서 이러한 API에 대한 액세스는 이제 개체를 만들고 간단한 기능을 사용하여 데이터를 검색하는 것만큼 쉽습니다. Web 3.0 API의 효율성을 입증하기 위해 Web 2.0 관점에서 중개 계좌에 돈을 입금하는 과정이 어떤지 생각하고 Web 3.0에서 이것이 어떻게 보이는지 살펴보겠습니다. 웹 2.0:

1. 백엔드는 특정 은행의 API를 호출하기 위해 사용자 승인을 받습니다(이 API, 자격 증명 등의 통합 및 이해 필요).

2. 은행 API는 중개 계좌로 ACH/전신 이체를 트리거합니다(ETA: 시간에서 일까지).

3. 브로커가 자금을 받으면 백엔드가 브로커의 API를 호출하여 거래를 수행합니다(아마도 훨씬 다른 API, 자격 증명 시스템 등).

4. 거래가 발생하고 조회를 위해 결과를 명시적으로 기록해야 합니다.

다음은 Web 3.0 코드 예입니다.
https://solidity-by-example.org/에서 수정

보시다시피, 두 가지 별개의 서비스를 사용하여 복잡한 금전 이체를 수행하면 API 통합, 자격 증명 및 대기 시간으로 인해 Web 2.0 작업에서 개발자에게 골칫거리가 됩니다. 위의 웹 3.0 스마트 계약에서 이것은 매우 읽기 쉬운 몇 줄의 코드로 두 개의 별개 서비스(소스 토큰/은행 및 Uniswap/브로커)로 수행할 수 있습니다. 또한 이 복잡한 FinTech 거래는 이 기사의 범위를 벗어나지만 며칠이 아닌 몇 초 만에 발생합니다.

전체적으로 스마트 계약 시대에 API 호스팅의 이점에 대한 실현은 많습니다. 우리는 모든 데이터 또는 서비스가 언어 고유 기능을 가진 개체로 볼 수 있고 고유한 주소가 있는 인터페이스의 재현 가능한 특성으로 인해 표준 프로토콜이 나타날 수 있으며 API 지불이 간소화될 수 있다는 점에 주목했습니다. 마지막으로 보너스로 이러한 차세대 API에는 서버 구성, 유지 관리 또는 클라우드 결제가 필요하지 않습니다. 일단 배치되면 수천 명의 블록체인 운영자가 이를 처리하고 각 거래의 가스 요금을 통해 지불합니다!

마지막 섹션에서는 Web 3.0의 가장 큰 발전이라고 생각하는 부분을 다룹니다. 제가 강조하고 싶은 것이 한 가지 더 있습니다. 놀랍도록 비슷해 보일 수 있습니다. 글쎄요, 똑같지만 관점은 Web 3.0을 보는 또 다른 재미있는 방법을 제공합니다. OOP 또는 객체 지향 프로그래밍은 동적 및 확장 가능한 코드를 생성하기 위해 변수와 함수를 보유하는 코드에서 객체를 사용하는 것을 말합니다.

변수와 함수는 이 기사의 주요 주제와 매우 유사합니다. 스마트 계약은 사실상 OOP에서 말하는 객체이며 코드의 스캐폴드는 변수, 함수 및 생성자가 있는 Java, Python 또는 C# 클래스와 다르지 않습니다. 그래서 우리가 그것을 합칠 때 이것은 무엇을 의미합니까? 개체가 온라인 상태가 되었습니다.

이는 액세스 제어를 사용하여 개체를 배포할 수 있음을 의미합니다. 물론 계약 형태의 여러 "서비스"가 다른 서비스가 동일한 작업을 수행하도록 직접 액세스하고 조작할 수 있습니다. 복잡한 자동차 역사와 타이틀을 위한 시스템을 만들고 싶을 수도 있습니다. 우리는 각 차량에 대한 객체/계약을 배포하고 다른 스마트 계약의 형태로 무한 마이크로서비스를 생성하여 동일한 객체에 대해 다양한 작업을 수행하는 동시에 모든 사용자에게 일부 가시성을 제공할 수 있습니다. 또는 다른 서비스에서 자체 데이터베이스에 액세스하는 더 깨끗한 방법을 원할 수도 있습니다. 이는 다음과 같이 쉽게 보일 수 있습니다.

이 예에서 데이터베이스는 모든 서비스에 포함할 수 있는 인터페이스를 통해 블록체인에서 안전하게 호스팅됩니다. 이것은 대부분의 타사 언어 기반 DB 라이브러리와 크게 다르지 않지만 초기화, 코드 이해 능력 및 데이터 유형 작업이 훨씬 더 강력하다고 생각합니다.

이 글에서 저는 암호화폐를 넘어 블록체인과 스마트 계약의 가능성을 보여주고 싶었습니다. 나는 여전히 이 기술의 암호화 측면에 관심이 있지만 토큰, NFT 및 "Blockchain"이라는 단어와 관련된 진부한 표현에서 내 견해를 멀리하려고 노력하고 있습니다.

모든 기술자가 암호가 블록체인이라는 것을 기억하는 것이 중요하지만 블록체인은 이 강력한 글로벌 현상의 새로운 사용 사례의 흐름을 허용하는 암호가 아닙니다. 내 아이디어는 현재 Web 3.0의 소프트웨어 엔지니어링 흐름, 데이터 액세스 표준화 및 미래의 백엔드 프레임워크로서의 스마트 계약에 중점을 두고 있습니다. 암호화를 넘어 블록체인에 대해 생각하기 시작할 때 아이디어가 어디로 가는지 알게 되어 기쁩니다!

반응형

댓글