백엔드 개발자의 눈을 통한 블록체인 개발

안녕하세요 여러분! 저는 꽤 오랫동안 백엔드 개발을 해왔고, 지난 몇 년 동안 점점 더 다양한 블록체인 프로젝트(EVM의 Solidity)를 작성해왔습니다. 블록체인에 뛰어드는 것은 저에게 쉽지 않았고, 백엔드 두뇌가 여러 번 고장났기 때문에 블록체인 개발로 전환하는 것에 대한 제 의견을 공유하기로 했습니다.

블록체인은 우리 세계를 앞으로 나아갈 수 있는 매우 멋진 기술입니다. 하지만 지금으로선 많은 사람들이 그것을 사고팔고 사기치고 사기를 치고 부양하는 데 사용합니다. 저는 암호화폐를 자산으로 고려하지 않을 것이고, 고려하지도 않을 것입니다.

네, 많은 다른 영상과 게시물에서 "여기, 이런 암호화폐는 지금 성장할 수 있고, 이런 암호화폐는 떨어졌습니다. 여러분, 투자합시다, 사봅시다..."라고 말합니다. 저는 그것에 대해 아무것도 말하지 않겠습니다.

한 가지만 말씀드리겠습니다. 돈을 벌기 위해 암호화폐를 피해야 합니다. 개발자라면 개발자로서 돈을 벌고 투자에 관여하지 않는 것이 좋습니다. 그리고 정말 투자하고 싶다면 암호화폐에 투자하지 마세요.

블록체인에 대하여, 그리고 그것이 흥미로운 이유

중요한 사항부터 시작하는 것이 좋습니다. 블록체인은 암호화폐가 아닙니다. 블록체인은 암호화폐가 구축된 기술이며 암호화폐를 블록체인이라고 부르는 것은 전체 개발 산업을 Javascript라고 부르는 것과 같습니다. 그렇습니다. JavaScript는 특별한 개발 사례인 듯하지만 개발에 대해 논의할 때 JavaScript를 의미하는 것은 아닙니다. 어떤 사람들은 JavaScript만 의미하지만...

돈을 위해 블록체인에 가다

가장 먼저 떠오르는 것은 돈입니다. 블록체인 개발자는 꽤 좋은 급여를 받습니다. 저는 개인적으로 그런 공석을 열었습니다. 저는 개인적으로 그런 공석에 응답했는데, 그곳에서는 하루에 같은 시간을 일하면서 같은 백엔드 개발자보다 더 많은 것을 얻을 수 있습니다. 블록체인 개발자는 블록체인 기반 스타트업에서 금만큼이나 가치가 있습니다. 특히 훌륭한 블록체인 개발자라면요!

좋은 백엔드 개발자는 누구인가요?

훌륭한 백엔드 개발자가 되는 것은 제품을 떨어뜨리거나 고치지 않고는 불가능합니다. 아마도 저는 패배자일 뿐이고 부정적인 경험을 통해서만 배우는 것일 수도 있지만, 제가 가진 이론은 다음과 같습니다.

1. 백엔드 개발자가 경험이 있다면 그는 프로덕션에서 솔루션을 실행한 적이 있을 것입니다.
2. Prod에서 실행해 보았다면, Prod가 어떻게 실행되는지 알고, 부하가 걸릴 때 제품에 어떤 일이 일어나는지 알 수 있을 것입니다.
3. 그가 서비스에 부하를 가했다면, 그는 가동 중단과 서비스 충돌을 포착했을 것입니다.
4. 그리고 그가 서비스 충돌을 포착했다면, 아마도 그는 그것을 발견했을 것입니다.

실패로 경험을 교환할 수는 없지만, 실패의 경험은 당신이 경험이 있다는 것을 깨닫게 해줍니다. 돈을 잃지 않고 훌륭한 블록체인 개발자가 되는 것은 어렵습니다.

• 아직 계약서에서 돈이 도난당하지 않았다면, 실제 돈으로 무언가를 시작한 적이 없다는 뜻입니다(계약서에 최소 1000달러 포함).
• 실제 돈으로 또는 테스트 네트워크(가짜 돈)에서만 무언가를 출시하지 않았다면, 블록체인이라는 독성이 강한 세계에서 무엇이 저를 기다리고 있는지 전혀 알 수 없습니다.
• 앞으로 무슨 일이 일어날지 모른다면 첫 출시에서 손해를 볼 것이고, 이는 내 실수에 대한 가장 먼저 대가를 치르는 위험을 감수할 의향이 있는 팀/회사의 몫입니다.

기술을 위한 블록체인으로 들어가다

위의 이미지는 라이트 형제가 세계 최초로 날았던 비행기를 보여줍니다. 비행기는 매우 형편없이 날았습니다. 하지만 비행기는 날았고, 당시 일반인의 비행기에 대한 태도는 다음과 같았습니다.

• 값비싼
• 불편한
• 불편하고 이해할 수 없다

그리고 이제 항공 산업은 우리 삶의 멋진 부분이 되어 몇 시간 안에 전 세계 사람들을 연결합니다. 물류는 이제 라이트 형제가 꿈에도 생각지 못했던 수준에 도달했습니다! 비행기 덕분에 전 세계가 다르게 살고 있습니다.

저는 지금 블록체인에 대해서도 똑같이 말하고 싶습니다. 비싸고 불편하고 그 이유가 불분명합니다. 제가 블록체인 개발에 몰두하기 전까지는 투자자(=햄스터)를 속이는 데 쓸모없는 것처럼 보였습니다. 하지만 다른 측면에서 살펴보면 변조 가능성 없이 모든 사실을 분산된 방식으로 저장할 수 있습니다. "조작 가능성 없이"는 중요한 세부 사항입니다.

하지만 아쉽게도 "블록체인"이라는 단어와 관련된 연관성은 오히려 지루하고 단조롭습니다.

• 비트코인
• 투자
• 스캠
• ETH, Ripple, {코인 이름 입력}
• 터질 듯한 거품

우리가 종이 돈 뭉치를 난로에 던지면 난로는 잘 타고 돈은 얼마 동안 열을 낼 것입니다. 하지만 그것은 터무니없는 일입니다.

블록체인도 마찬가지입니다. 돈과 암호화폐에만 사용하는 것은 나쁘지만, 다른 것은 아직 뿌리를 내리지 못하고 있습니다...

모든 제품 개발의 주요 동인 중 하나는 돈입니다. 훌륭하고 강력한 돈을 벌 수 있는 무언가가 있다면, 이 "무언가"가 적극적으로 개발될 것입니다. 그리고 그것이 지금까지 블록체인을 기반으로 한 금융 프로젝트가 누군가를 위해 돈을 벌고 다른 누군가를 위해 돈을 잃는 것에 기반을 두고 있는 이유입니다.

블록체인 개발 이론

분산

중앙 집중형 서비스와 분산형 서비스의 차이점은 무엇일까요? 중앙 집중형 시스템부터 시작해 보겠습니다. 저와 다른 사람이 있고, 우리는 은행이나 다른 제공자와 같은 서비스를 사용하여 이체를 용이하게 하기로 했습니다.

중앙화된 서비스인 은행이 있다고 가정해 봅시다. 저는 이 은행에 "이 사람에게 100달러를 이체해 주세요"라고 명령합니다. 은행은 제가 100달러 적게 가지고 있고 다른 사람이 100달러 더 많이 가지고 있다고 기록합니다.

하지만 중앙 집중형 서비스의 문제점은 무엇일까요? 이 중앙 집중형 서비스 뒤에는 소유자가 있지 않나요? 보통은 대기업, 지분, 상관없지만 우리의 경우 한 사람이면 됩니다. 이 한 사람이 "이렇게 합시다. 알렉스가 100달러를 보내게 하세요. 하지만 아무도 이 100달러를 받지 못할 겁니다. 저는 더 필요합니다."라고 말할 수 있습니다.

중앙 집중형 서비스에는 소유자가 있습니다. 문제는 소유자가 부정적인 결정을 내려 돈을 빼앗을 수 있다는 것입니다. 그리고 그것은 단순히 "자신을 위해 돈을 빼앗는 것"에 관한 것이 아닐 수도 있습니다. 예를 들어, "은행에 100,500달러가 있습니다"라고 쓰고 모든 예금자가 그 돈을 쫓지 않기를 바랄 수 있습니다... SVB와 다른 은행이 망한 것처럼 말입니다.

비트코인은 자금 관리를 분산화하기 위해 발명되었습니다.

분산 서비스는 각 노드가 정보를 저장하고 전송하는 노드 네트워크에서 구축됩니다. 간단히 말해서, 노드는 어떤 정보가 올바른 것으로 간주되고 어떤 정보가 올바르지 않은지, 그리고 어떻게 저장할지에 대해 합의했습니다.

우리는 방에 비유할 수 있습니다. 한 사람이 다른 사람들이 보관하기를 원하는 정보를 외칩니다. 그런 다음 방에 있는 모든 사람이 외친 후 저장한 정보로 작업합니다.

예를 들어, 블록체인은 송금에 대한 메시지나 정보를 저장하고 전송할 수 있습니다. 네트워크 참여자는 기록하기 전에 정보를 검증합니다.

방 비유에서 나는 "샘에게 100달러를 이체하고 있어."라고 소리친다. 모두가 내가 100달러 적게 가지고 있고 샘이 100달러 더 많이 가지고 있다고 기록한다. 만약 갑자기 이체 전에 내가 100달러보다 적게 가지고 있다면 아무도 거래를 기록하지 않을 것이다.

스마트 계약

블록체인에서 Solidity 언어로 스마트 계약을 만들 수 있습니다(EVM의 블록체인의 경우). 스마트 계약은 블록체인 네트워크에서 실행되는 프로그램입니다. 여기에는 검증 메커니즘, 오류 처리 및 기타 기능이 포함될 수 있습니다.

다시 말해, 우리가 명령을 외치는 방의 경우, 스마트 계약은 내가 방의 각 참가자에게 미리 프로그램 코드를 제공하는 것입니다. 내 명령에 어떻게 반응해야 하는지, 무엇을 확인해야 하는지, 무엇을 저장해야 하는지. 그리고 나서 나는 "이 매개변수로 프로그램을 실행하세요"라고 외칩니다. 그러면 모두가 지시를 따릅니다. 간단한 스마트 계약의 한 예는 데이터를 추가하고 수신하는 기능이 있는 정보 저장입니다. 계약 코드는 바이트 코드로 컴파일되어 실행을 위해 블록체인 참가자에게 전달됩니다.

이 스마트 계약으로 전송되는 특정 요청을 어떻게 처리할까요? 백엔드와 비유하자면, POST 및 GET 요청을 처리할 수 있는 서비스입니다. POST는 정보를 저장합니다. 여기서 GET은 우리가 저장한 정보를 다시 보냅니다. 이는 일반적으로 모든 백엔드가 구조화되는 방식입니다.

백엔드에서 개발하는 동안, 저는 API, 데이터베이스, 그리고 데이터 저장 및 처리와 관련된 모든 것이 제 쪽에서 이루어진다는 방식에 매우 익숙해졌습니다. 그리고 저는 이미 마치 벽 뒤에 있는 것처럼, 미리 준비된 시나리오에 따라 사용자가 이 데이터로 작업할 수 있는 인터페이스를 제공합니다.

예를 들어, 사용자 1이 와서 POST 방식을 통해 콘텐츠(예: 게시물)를 저장합니다. 그런 다음 사용자 2가 와서 GET 방식을 사용하여 이 콘텐츠를 검색합니다. 사용자는 콘텐츠가 어디에 어떻게 있는지 모릅니다. 백엔드는 그들에게 블랙박스입니다.

여기서 우리는 블록체인의 매우 중요한 부분에 도달합니다. 방 안에 서 있는 노드나 사람들의 예로 돌아가 봅시다. 백엔드와 비유를 사용하여 다음과 같은 일이 발생한다고 가정해 보겠습니다. 블록체인에 "ADD" 메서드를 던지면 모든 사람이 로컬에서 메서드를 호출한 다음 블록체인 사본에서 정보를 가져올 수 있습니다.

그래서, 우리는 노드가 정보를 가져오는 네트워크에 여러 개의 서로 다른 사본을 가지고 있습니다. 블록체인의 문제점은 각 쓰기 작업에 대해 실제 돈을 지불해야 한다는 것입니다. 이는 네트워크 통화로 지불되며, 실제 돈으로 구매할 수 있습니다(또는 채굴할 수 있지만, 오늘은 그게 아닙니다).

블록체인과 백엔드를 비교해보면 다음과 같습니다.

• 기존 서비스에서는 무료로 쓰고 무료로 읽고 의존적으로
• 블록체인에서 우리는 수수료를 받고 글을 쓰고, 무료로 독립적으로 읽습니다.

예를 들어, Telegram에는 중앙화된 데이터베이스가 있습니다. 우리는 항상 무료로 액세스하여 메시지, 사진, 비디오 등을 다운로드할 수 있습니다. 하지만 Telegram의 서버가 갑자기 다운되면 액세스할 수 없습니다.

블록체인에 정보를 쓰는 것을 포함하여 일부 스마트 계약 명령을 실행하려면 EVM 가상 머신에 비용을 지불해야 합니다. 계산을 수행하고, 무언가를 더하고, 곱하고, 곱하고, 곱하고, 결국 블록체인 저장소에 새로운 아티팩트가 나타나 블록체인에 참여하는 모든 노드에서 업데이트됩니다.

모든 네트워크 참여자는 수백 기가바이트의 블록체인 데이터가 있는 전체 노드를 실행하고 로컬에서 작업할 수 있습니다. 또한 전체 블록체인을 저장하지 않지만 네트워크의 전체 노드에 액세스하여 필요한 정보를 검색할 수 있는 가벼운 버전의 노드를 사용할 수도 있습니다.

이 아이디어는 블록체인의 각 엔트리가 블록체인 상태의 변화가 발생하는 거래의 묶음을 포함하는 블록이라는 것입니다. 각 연속 블록은 해싱 알고리즘을 기반으로 하는 체인의 이전 블록에 따라 달라집니다.

일반적으로 기본적이지만, 데이터가 변경되면 재채기할 때마다 비용을 지불해야 한다는 점을 명심해야 합니다. 그런데, 계약 배포도 블록체인에 기록되고 저렴하지 않습니다!

스마트 계약의 배포

백엔드 분야에서 저는 대략 다음과 같은 기능 개발 라이프사이클을 경험해 왔습니다.

• 코드를 작성했습니다
• Gitlab에서 출시했습니다
• GitLab CI는 테스트를 실행하고 모든 것을 확인합니다.
• 모든 것이 정상이면 CI는 서버에 새 버전의 애플리케이션을 배포하기 시작합니다.

즉, 우리는 이런 방식으로 일하는 데 익숙하며, 무료로 이루어집니다. 조건부로 무료이기는 하지만, 우리는 서버에 비용을 지불하기 때문입니다. 블록체인은 어떨까요?

블록체인의 경우, 우리는 우리의 "애플리케이션"(스마트 계약)의 새로운 코드를 블록체인에 작성해야 합니다. 위에서 말했듯이, 우리는 각 레코드에 대해 비용을 지불해야 합니다. 스마트 계약에 대한 거래를 하기 전에, 우리는 스마트 계약의 배치와 거래를 해야 합니다.

그러면 클라이언트/서비스 서버는 계약에 대한 정보를 받거나 저장하기 위해 모든 노드에 연락합니다.

엄청난 수의 노드에 알림을 보내야 합니다. "여러분, 여기 제 거래에서 알고리즘을 적용해야 하는 계약의 바이트코드가 있습니다." 블록체인을 학습하는 모든 노드에 동일한 코드가 나타나도록 하는 것이 필수적이며, 누가 호출하든 어떻게 호출하든 동일한 방식으로 실행됩니다. 메커니즘은 동일하고 변경되지 않습니다. 게다가 스마트 계약이 어떤 노드에서든 다르게 작동하도록 변경할 수 있는 방법은 없습니다.

아래는 제가 꽤 오래 전에 ETH 네트워크에 계약을 입금한 거래의 예입니다.

실제로 사용되지 않은 테스트 계약이었습니다. 배포를 위해 200달러의 ETH를 지불했습니다. 즉, 우리는 아직 이 계약에 대해 아무것도 하지 않았습니다. 요청은 하나도 없었지만 200달러는 이미 지출되었습니다. 잘못된 계약의 이 잘못된 배포를 기억하면 여전히 슬픕니다...

데이터 저장

데이터 저장소에 대해 이야기해 봅시다. 우리는 모두 PostgreSQL , MySQL , MongoDB , Redis 및 기타 서비스를 백엔드에 두고 데이터를 편리하게 작업하는 데 익숙합니다. 블록체인의 경우 이와 비슷한 것은 없습니다.

블록체인에서 스토리지는 다른 언어의 클래스에 있는 변수처럼 구현됩니다. 즉, 키 값이나 배열일 뿐입니다. 편리한 링크가 있는 관계형 테이블은 없습니다. 그냥 변수에 쓰고 행복하세요.

현재로서는 블록체인에서 스토리지를 구성하는 다른 방법을 모릅니다. 글쎄요, 상황이 이미 바뀌었을 수도 있고, 이 글을 읽을 때 그런 방법이 있을 수도 있습니다. 댓글에 적어주세요.

예를 들어, 배열에 저장하지 않고 키로 정보를 저장하고 싶다면 - 이에 대한 매핑이 있습니다.

달러 기호가 그려진 데에는 이유가 있습니다. 각 세트에 대해 네트워크 수수료가 부과되기 때문입니다.

통증과 고통

이 블록에서 저는 저를 놀라게 하거나 화나게 한 일들에 대해 논의할 것입니다. 이 문서에 있는 것보다 훨씬 더 많은 것들이 있지만, 저는 제 실무에서 처음으로 저를 강타한 일들을 공유할 것입니다.

대부분의 "고통"은 어떤 논리적인 이유로 이해할 수 있다는 점을 알아두는 것이 중요합니다. 하지만 그것이 내 백엔드 뇌의 고통을 없애지는 못합니다.

예를 들어, 저는 우리가 무엇이든 모든 요소를 쉽게 살펴볼 수 있다는 사실에 익숙합니다. 배열이든 객체든 맵이든 상관없습니다. Solidity에서 이 목적을 위해 우리는 모든 키의 배열을 별도로 저장한 다음, 필요한 경우 모든 키를 살펴보고 각 키의 맵에서 요소를 검색해야 합니다. 글쎄요, 우리는 또한 키 배열과 초기화에 대한 추가 쓰기에 gas를 사용합니다.

우리는 편리한 열쇠 분류 도구도 모두 구할 수 없어요.

벌채 반출

로깅 상황도 불쾌합니다. 저는 개발 환경에서 디버거를 통한 디버깅에 익숙하지만, 여기서는 일반 로깅조차 잊어야 합니다.

Typescript에서는 console.log(a) 쓰고 콘솔에서 즉시 출력을 얻는 데 익숙합니다. Solidity에서는 로컬 하드햇 개발 환경 에서 실행할 때만 작동하는 console.log 가 있습니다. 그리고 좋은 점은 필요한 것을 분할한 후 계약을 배포하기 전에 이 모든 로깅을 삭제해야 한다는 것입니다. 그렇지 않으면 계약이 더 중요해지고 배포 비용이 더 많이 들고 프로덕션에서 전혀 작동하지 않기 때문입니다.

결국 우리가 이미 전투 중인 프로젝트를 실행할 때, 우리는 무엇이 잘못되었는지 보고 싶어하고, 무엇이 잘못되었는지 볼 수는 없습니다. 하지만 무엇이 잘되었는지는 볼 수 있습니다. 스마트 계약 내에는 이벤트 시스템이 있습니다. 예를 들어, 이 인덱스에 이 값으로 새 항목이 추가되는 이벤트를 원한다고 가정해 보겠습니다.

우리는 이 이벤트를 set 메서드 내부에서 호출하고, 성공적으로 실행될 때만 로그를 볼 수 있습니다. 무언가 잘못되었거나, 계약에 대한 호출이 여러 번 있었거나, 트랜잭션 충돌이 발생한 경우, 블록체인의 정보가 롤백되기 때문에 로그도 저장되지 않습니다.

여러 스마트 계약 체인을 사용한다고 가정해 보겠습니다. 첫 번째 계약에서 일부 이벤트를 호출한 다음 두 번째 계약이 호출되어 다른 이벤트를 호출하고 두 번째 계약 내부에서 호출된 모든 것이 삭제됩니다. 모든 것이 한 번에 완전히 삭제됩니다.

블록체인 내부에서 무슨 일이 일어나는지 기록할 때는 매우 조심해야 하며, 익숙한 일반 로깅은 여기서는 사용할 수 없다는 점을 명심해야 합니다.

또 다른 불쾌한 점은 쓰기 함수에서 거래 정보를 얻을 수 없다는 것입니다. 블록체인에 무언가를 쓰는 거래(예: 유료 거래)를 수행하면 return 스마트 계약과 통합된 서비스에 아무것도 제공하지 않습니다. 이 반환은 스마트 계약 자체 또는 view (무료) 함수에서만 작동합니다.

예를 들어, 블록체인에 새 값을 추가할 때 저장 후 저장소 크기를 알아내고 싶을 수 있습니다(위의 스크린샷). 즉, 이벤트를 통해서만 정확히 무엇이 추가되었는지 알아낼 수 있습니다. 그러기 위해서는 해당 트랜잭션 내에서 트리거된 이벤트를 끌어와야 합니다.

문자열 작업

여기서 나에게는 놀라운 점이 하나 있었습니다. 문자열을 정상적으로 다루는 것은 불가능합니다. 블록체인은 문자열을 위해 만들어지지 않았습니다. 예제로 넘어가겠습니다.

아래 코드는 아무 문제 없이 작동합니다.

그리고 이 코드는 더 이상 작동하지 않습니다:

저는 오랫동안 문자열을 정상적으로 다루는 데 익숙해져 있었습니다. 문자열의 문자를 바꾸고, 문자열을 자르고, 연결하는 것 말입니다. 이 모든 것이 바로 사용할 수 있는 것은 아닙니다. 문자열 길이를 표시할 가능성도 없습니다. 즉, 이 코드는 컴파일되지 않습니다.

문자열의 길이가 정말 필요하다면, 문자열을 바이트로 변환한 다음 바이트 수를 세면 됩니다. 하지만 문제는 일부 특수 문자가 1대1로 바이트로 변환되지 않는다는 것입니다. 그리고 일부는 단순히 변환되지 않고 트랜잭션이 충돌할 수 있습니다.

문자열을 처리하고 일반 문자열을 테스트하는 스마트 계약을 작성하게 될 수 있습니다. 그러면 처리되지 않는 문자열이 도착하고 모든 것이 충돌하거나 특수 문자로 인해 문자열 길이가 잘못 계산됩니다.

문자열에 대한 결론은 간단합니다. 문자열로 작업하지 말고 계약 내부에서 문자열에 의존하지 마세요. 문자열을 저장하는 것이 중요하다면 바이트를 저장하고 바이트에 의존하고 서비스 자체에서 문자열을 바이트로 변환하세요.

외부 통화 문제

블록체인의 주요 특징의 확장인 다음 복잡성은 격리입니다. 블록체인에 있는 모든 데이터는 블록체인 내부에서 생성되거나 외부에서 블록체인으로 전송됩니다. 하지만 블록체인 자체는 외부 세계에 영향을 미칠 수 없습니다. 다른 스마트 계약만이 영향을 미칠 수 있습니다.

문제는 모든 스마트 계약 명령이 네트워크의 각 참여자에서 실행된다는 것입니다. 그리고 모든 노드에서 동일한 정보가 수신될지 확신할 수 없으므로 외부 소스를 신뢰할 수 없습니다. 각 노드가 다른 데이터를 가진 다른 버전의 블록체인을 갖게 되고 블록체인이 붕괴될 수 있습니다.

그리고 "현재 외부 온도를 알아내는" 사소한 작업은 불가능한 일이 됩니다. 날씨가 항상 필요한 것은 아니지만, 일부 데이터(예: 환율 또는 외부 시스템의 현재 상태)는 필수적입니다. 해결책은 다음과 같은 접근 방식에 있습니다.

1. 우리는 운영자 계약을 맺었는데, 여기서 우리 서비스는 "이러한 매개변수를 사용하여 이 서버에 요청을 보내세요"와 같은 작업을 보냅니다.
2. 계약에서 이벤트가 발생합니다.
3. 별도의 백엔드는 이 이벤트를 구독하고 이벤트에서 "요청을 보낼 위치와 매개변수" 및 "여기에 이 계약에 넣으세요"라는 답변을 포함하는 정보를 추출합니다.
4. 서버는 올바른 매개변수와 함께 요청을 보내고 응답을 받습니다.
5. 서버는 필요한 계약에 대한 응답을 보냅니다.
6. 그 다음에 이 데이터를 어떻게 처리해야 할지가 결정됩니다.

그것은 매우 긴 체인으로 밝혀졌습니다. 이야기의 슬픈 점은 돈이 "그런 요청에 대해 나를 위해 가세요"라는 양식의 첫 번째 요청에서 가져가고 두 번째 요청에서는 요청을 실행한 서버에서 이미 수행된다는 것입니다.

예를 들어, 각 단계마다 50k 가스가 필요합니다. 거래를 시작하고 50k GAS LIMIT를 입력하고 괜찮을 것이라고 생각합니다. 하지만 예를 들어, 새로운 날씨 변화를 저장하는 메커니즘이 변경되었습니다. 이제 온도가 10도 이상이면 참가자 중 한 명에게 돈을 이체해야 합니다. 논리가 확장되어 이제 예를 들어 거래당 80k 가스가 필요합니다.

결국, 두 번째 거래에서 이미 거래에 필요한 가스가 부족하여 전체 체인이 붕괴됩니다. 외부 호출을 둘러싼 이런 "채소 정원"은 이런 프로젝트를 더 복잡하게 만듭니다. 아마도 외부 세계와 하드 커넥션이 있다면 프로젝트에 블록체인을 선택하지 말아야 할 것입니다.

미리 결정될 수 없는 일반적인 무작위성도 없습니다. 이 무작위성은 또한 다른 제공자에 의해 "있는 그대로" 제공됩니다. 무작위 값이 스마트 계약에 정기적으로 기록됩니다. 그러나 실제 금융 프로젝트에 그런 것을 신뢰하는 것은 위험합니다.

block.timestamp 변수의 값이 블록 채굴자에 의해 설정된다는 사실은 특별한 주의를 기울일 만합니다. 물론 채굴자가 블록을 채굴하는 사람이 자신이고 시간을 대체할 수 있다는 것을 미리 알고 있다고 상상하기는 어렵습니다. 그래도 가설적인 가능성이 있습니다. 이 위험은 15초의 맥락에서 관련이 있으며, 분과 긴 시간 간격에 의존한다면 그런 문제는 없습니다.

보안 문제

보안에 대해서는 많이 이야기할 생각이 없습니다. 하지만 중요한 측면을 강조하겠습니다. 블록체인의 모든 것은 모든 사람이 볼 수 있습니다. 다른 사람이 접근할 수 없는 유일한 것은 개인 키입니다. 스마트 계약 코드는 감사를 통과하고 스마트 계약 사용자가 신뢰할 수 있도록 공개됩니다.

감사 절차는 회사가 스마트 계약 코드를 살펴보고 이 특정 계약이 이 주소에 게시되었는지 확인하기 위해 고용된다는 것을 의미합니다. 계약의 보안 문제가 확인되고 개발자가 선언한 대로 됩니다. 그런 다음 감사 회사는 "이 계약은 당사에서 검증했습니다. 신뢰할 수 있습니다"와 같은 정보를 웹사이트에 게시합니다.

불변 변수

하지만 계약 코드가 제공되지 않더라도 쉽게 디컴파일할 수 있습니다. 예를 들어, 다음 코드에는 변경 불가능한 변수가 있습니다. 아래 코드에서 모든 곳을 상수로 간단히 대체합니다.

이 계약을 배포하고 디컴파일러를 통해 열면 다음이 표시됩니다.

즉, 우리는 변수의 값을 즉시 얻습니다.

개인 변수

저는 백엔드에서 침착할 수 있는 데 익숙했고, 메모리 액세스 없이 읽을 수 있는 개인 변수의 값은 문제가 될 것입니다. 여기서도 마찬가지입니다. 다만 모든 사람이 "메모리"에 액세스할 수 있다는 것입니다.

우리는 변수 amount private라고 불렀습니다. 스마트 계약을 배포한 다음 간단한 코드 조각으로 값을 가져옵니다.

그렇게 하면 무엇이든 꺼내올 수 있습니다. 그러니 스마트 계약에 민감한 것을 저장하는 것에 대해 생각하지 마세요!

스마트 계약 배포

기본적으로 변경 사항을 롤백하는 것은 불가능합니다. 스마트 계약은 한 번 할당 해제되고 아무것도 변경할 수 없습니다. 시간이 끝날 때까지 블록체인에 남아 있을 것입니다.

업그레이드 가능한 스마트 계약

그래서 모든 것을 한 번에 정확하고 잘 써야 합니다. 저는 그렇게 할 수 없으므로, 저는 재빨리 흥미로운 해결책을 생각해냈습니다. 업그레이드 가능한 계약 입니다. 그들의 메커니즘은 다음과 같이 작동합니다.

1. 계약서의 첫 번째 버전(계약서 V1)이 게시되었습니다.

2. 프록시 계약이 게시되었으며 다음과 같은 작업이 있습니다. 모든 요청을 1대1로 계약 V1에 전달하거나 자체 저장소를 사용하고 대상 계약의 논리만 사용합니다.

3. 또한 사용자는 주 계약과 동일한 방식으로 프록시 계약과 통신합니다.

   계약을 업데이트해야 하는 경우 관리자는 Contract V2를 배포하고 admin-contract를 통해 proxy-contract에 구현이 이제 Contract V2의 주소에 있다고 알립니다.

4. 다음으로, 사용자는 프록시와 통신하며, 계약 V2의 메커니즘은 이미 실행되었습니다.

5. 다음으로, 사용자는 프록시와도 통신하며, 계약 V2의 메커니즘은 이미 실행되었습니다.

이 메커니즘에는 여러 가지 제한과 트릭이 있습니다. 예를 들어, 이전 버전의 변수는 새 버전의 계약에서 변경할 수 없습니다. 변수가 더 이상 필요하지 않으면 여전히 그대로 두고 새 계약에 채워 넣어야 합니다.

물론, 이 솔루션과 다른 많은 솔루션에는 이미 기성품 해결 방법이 있습니다. 이러한 개발의 주요 공급업체는 OpenZeppelin 입니다. 따라서 다행히도 바퀴를 다시 발명할 필요가 없습니다.