<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>CoinYQ 한국어 크립토 스토리</title>
    <link>https://coinyq.com/ko/stories</link>
    <description>사람, 사건, 사기, 프로토콜 전쟁으로 읽는 근거 있는 암호화폐 이야기</description>
    <language>ko-KR</language>
    <lastBuildDate>Sat, 26 Sep 2026 00:00:00 GMT</lastBuildDate>
    <atom:link href="https://coinyq.com/ko/rss.xml" rel="self" type="application/rss+xml" />
    <item>
    <title>테조스 Athens — 투표가 실행 규칙이 되기까지</title>
    <link>https://coinyq.com/ko/stories/tezos-athens-vote-becomes-protocol</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/tezos-athens-vote-becomes-protocol</guid>
    <pubDate>Sat, 26 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[2019년 테조스 참여자들은 Athens의 두 버전 중 하나를 골랐다. 첫 개정이 시험한 것은 투표만이 아니었다. 가동 중인 체인과 계정, 주변 도구를 새 규칙으로 이어 가야 했다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/tezos-athens-vote-becomes-protocol.webp" alt="테조스 Athens — 투표가 실행 규칙이 되기까지" /></p><p>2019년 테조스 참여자들은 Athens의 두 버전 중 하나를 골랐다. 첫 개정이 시험한 것은 투표만이 아니었다. 가동 중인 체인과 계정, 주변 도구를 새 규칙으로 이어 가야 했다.</p><h2>하나의 업그레이드, 두 가지 선택</h2><p>2019년 초, 테조스 참여자들에게 주어진 질문은 단순히 업그레이드가 마음에 드느냐는 것이 아니었다. Nomadic Labs는 두 버전을 제안했다. Athens A는 당시 지분증명에 쓰이던 지분 단위인 롤을 1만 tez에서 8,000 tez로 줄이고, Athens B는 그대로 유지했다. 가스 한도는 두 안 모두 높였다. 작은 숫자 하나가 선택을 구체적으로 만들었다. 네트워크가 실제로 실행할 규칙을 골라야 했다.</p><p>제안의 실체는 취지를 적은 문서에 그치지 않고 실행 가능한 OCaml 코드였다. Nomadic Labs는 변경 사항을 패치로 나누어 공개하고, 설명한 동작이 코드에 제대로 구현됐는지 읽어 보라고 권했다. 표를 던질 대상이 분명했다. ‘네트워크를 개선하자’에 동의하는 것과 바로 이 프로그램을 선택하는 것은 다른 약속이었다.</p><h2>투표는 전환 과정의 일부였다</h2><p>다음 단계로 나아간 것은 Athens A였다. 블록을 만드는 대표자인 베이커들이 지분에 가중치를 둔 절차에 참여했다. 제안 선택, 탐색 투표, 시험 기간, 최종 승인 투표가 이어졌다. 사람마다 똑같은 한 표를 주는 방식은 아니었다. 당시 TQ Tezos의 제이컵 알럭이 남긴 기록에는 여러 포럼과 채팅 채널에서 벌어진 토론도 나온다. 표를 체인에 기록한다고 숙의 전체가 소프트웨어 안으로 옮겨 가는 것은 아니었다.</p><p>새 규칙이 이미 가동 중인 시스템을 이어받는다는 점에서 시험은 중요했다. Nomadic Labs는 메인넷 상태를 대상으로 전환을 시험하고 시간과 저장 공간 비용을 측정했다. 기존 계정과 계약을 가져와 시작하는 시험 체인은 텅 빈 시연보다 현실적인 점검 기회를 줬다. 코드를 선택했다는 사실만으로 전환이 잘 된다는 보장까지 생기지는 않았다.</p><h2>실제로 바뀐 것</h2><p>Athens는 2019년 5월 적용됐다. 당시 프로토콜 문서에는 8,000 tez로 줄어든 롤과 늘어난 가스 한도가 기록돼 있다. 놓치기 쉬운 조건도 있다. 블록 안에서 가능한 계산 단계는 두 배가 됐지만 입출력 작업 수는 늘지 않았다. 가스 계산 방식도 바뀌었다. 따라서 ‘모든 거래의 처리 용량이 두 배’라고 설명하면 틀린 기대를 준다. 이 수치는 당시 개정 내용이지 오늘날의 베이킹 참여 요건이 아니다.</p><p>자체 개정이 연결된 모든 앱에 아무 일도 필요 없다는 뜻도 아니었다. Athens는 다른 소프트웨어와 주고받는 인터페이스의 필드 이름을 바꿨다. 문서는 지갑·탐색기·도구 개발자가 전환을 지원하는 방법을 안내했다. 프로토콜은 개정 장치를 통해 승인된 규칙을 채택할 수 있었지만, 주변 생태계에는 여전히 할 일이 남았다.</p><h2>판단을 끝내는 대신, 다시 쓸 수 있는 절차</h2><p>2019년 10월에는 Babylon이 뒤를 이었다. 첫 개정은 네트워크가 다시 사용할 수 있는 절차가 됐다. Athens의 의미는 구체적인 프로그램 중 하나를 고른 결정이 실제 적용으로 이어졌다는 데 있다. 앞으로 모든 표결이 현명하거나 모든 구현이 안전하리라는 증명은 아니었다. 제안에서 작동하는 규칙으로 가는 길이 생겼고, 그 길에는 계속 사람의 검토가 필요했다.</p><h2>출처</h2><ul><li><a href="https://research-development.nomadic-labs.com/athens-our-proposals-for-the-first-voted-amendment.html">Nomadic Labs: Athens 두 제안·코드·전환 시험</a></li><li><a href="https://medium.com/tqtezos/reflecting-on-athens-the-first-self-amendment-of-tezos-4791ab3b1de1">제이컵 알럭: 첫 개정의 투표와 공개 토론 기록</a></li><li><a href="https://octez.tezos.com/docs/protocols/004_Pt24m4xi.html">Octez: 당시 Athens 규칙 변경과 도구 전환 안내</a></li><li><a href="https://tezos.foundation/update-week-of-16-december-2019-the-year-in-review/">테조스 재단: 2019년 Athens·Babylon 회고</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>킹스 오브 리온 — NFT 앨범을 사면 무엇이 오는가</title>
    <link>https://coinyq.com/ko/stories/kings-of-leon-nft-album-beyond-token</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/kings-of-leon-nft-album-beyond-token</guid>
    <pubDate>Sat, 26 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[2021년 3월 킹스 오브 리온은 앨범에 NFT와 금색 바이닐, 별도 공연 혜택 경매를 결합했다. 한 팬의 구매 기록은 토큰을 받는 일이 전체 경험의 한 단계였음을 보여 준다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/kings-of-leon-nft-album-beyond-token.webp" alt="킹스 오브 리온 — NFT 앨범을 사면 무엇이 오는가" /></p><p>2021년 3월 킹스 오브 리온은 앨범에 NFT와 금색 바이닐, 별도 공연 혜택 경매를 결합했다. 한 팬의 구매 기록은 토큰을 받는 일이 전체 경험의 한 단계였음을 보여 준다.</p><h2>토큰은 왔다. 레코드는 어디로 오는가</h2><p>음악 필자 제이미 파멘터는 2021년 3월 킹스 오브 리온의 NFT를 샀다. 구매 뒤 계정에는 수집품이 보였다. 그런데 앨범은 어떻게 듣고 바이닐은 어떻게 받는지 여전히 궁금했다. 그때까지 우편 주소를 입력한 적이 없었다. 그의 직접 구매기는 이 실험의 중요한 틈을 포착한다. 토큰 거래의 성공과 레코드 주문의 완료는 같은 사건이 아니었다.</p><p>상품은 앨범 When You See Yourself의 3월 5일 출시에 앞서 3월 3일 발표됐다. 킹스 오브 리온은 YellowHeart와 NFT Yourself를 준비했고, 밴드의 창작 파트너 Night After Night가 아트를 맡았다. 발표된 기본 패키지는 50달러짜리 NFT 수집품에 한정판 Golden Eye 바이닐을 묶었다. 화면 속 물건과 턴테이블에 올릴 물건이 함께 팔린 셈이다.</p><h2>기획자들은 무엇을 바꾸려 했을까</h2><p>출시 발표에서 YellowHeart는 아티스트와 팬이 직접 연결되는 관계를 목표로 제시했다. 수집품에는 크리에이티브 디렉터 케이시 맥그래스와 밴드 멤버 매슈 팔로윌이 촬영한 사진 등 밴드의 시각 자료를 사용했다. 디지털 물건이 앨범과 알아볼 수 있는 관계를 갖게 한 것이다. 제안의 핵심은 음원 형식을 하나 더 만드는 데 그치지 않았다. 팬이 이번 발매의 특정한 흔적을 구매해 간직하는 방식이었다.</p><p>YellowHeart의 조슈아 카츠 대표는 Pollstar에 투명한 티켓 재판매와 공연이 끝난 뒤에도 의미를 갖는 수집품을 더 긴 목표로 설명했다. 이는 플랫폼의 지향점이지 모든 재판매와 미래 공연이 원활하게 작동했다는 증거는 아니다. 이전 가능한 기록은 다음 보유자를 가리킬 수 있었다. 혜택을 제공할 때 그 보유자를 인정하는 일은 여전히 밴드와 협력사가 맡아야 했다.</p><h2>금색 레코드와 골든 티켓은 다른 상품이었다</h2><p>컬렉션에는 여섯 개 Golden Ticket의 별도 경매도 있었다. 발표된 혜택은 평생 각 투어에서 선택한 한 공연의 앞줄 좌석 네 개였다. 모든 공연에 입장한다는 약속도, 일반 앨범 패키지에 포함된 혜택도 아니었다. 이 구분은 중요하다. ‘킹스 오브 리온 NFT’라는 말 아래 혜택과 가격이 크게 다른 상품이 있었기 때문이다.</p><p>앨범 자체는 일반적인 감상 경로로도 들을 수 있었다. NFT 패키지가 제공한 것은 수집품, 음원 다운로드, 특별판 바이닐이었다. 노래를 들으려면 반드시 NFT를 사야 하는 구조로 바뀐 것은 아니었다. 팬이 선택할 문제는 블록체인이 감상을 허락하느냐가 아니라 어떤 추가 경험을 구매하느냐였다.</p><h2>구매 버튼 뒤에도 이어진 절차</h2><p>파멘터는 OpenSea 계정과 MetaMask 지갑을 만들고 이더를 옮긴 뒤, 구매에 별도의 가스 수수료가 필요하다는 사실을 알게 된 과정을 기록했다. 토큰을 받은 후에는 교환 안내를 찾아 커뮤니티의 도움을 구했다. 바이닐을 받으려면 YellowHeart에서 자신의 정보를 확인해야 한다고 안내받았다. 모든 고객의 경험을 대표하는 수치는 아니지만, 단순해 보이는 앨범 가격 뒤에 어떤 일이 숨어 있었는지 보여 주는 한 구매자의 기록이다.</p><p>각 단계의 역할은 달랐다. 시장은 수집품을 제시하고, 지갑은 거래를 승인하며, 네트워크는 거래를 처리했다. 파멘터의 경우 상품 가격만큼만 지갑에 넣어 두어서는 이 비용을 모두 충당하지 못했다. 구매 시도의 실패로 부족한 가스비는 드러났지만, 토큰이 도착한 뒤에도 우편 주소 문제는 따로 남았다. 한 단계의 성공이 다음 단계에 남은 일을 가릴 수 있었던 셈이다.</p><p>기획자들도 이 어려움을 인정했다. 4월 Pollstar 인터뷰에서 밴드 매니저 앤디 멘델슨은 처음 들어온 팬들이 지갑·거래소·수수료를 다루는 데 겪는 어려움을 설명했다. 기사는 Golden Ticket의 새 소유자가 밴드와 YellowHeart에 다시 등록할 수 있다고도 전했다. 토큰은 옮겨 다니며 소유 기록을 남길 수 있지만, 그 소유자를 약속된 경험과 연결하는 일에는 사람과 서비스가 필요했다.</p><h2>두 번째 소유자에게는 다른 답이 필요하다</h2><p>파멘터는 음원 다운로드가 한 번 제공되는 혜택이고 바이닐 교환 신청에는 1년의 기한이 있다고도 기록했다. 이는 2021년 3월 구매기에 남은 조건이며 현재의 교환 안내가 아니다. 이 조건들은 지갑의 썸네일만으로는 드러나지 않는 차이를 만든다. 수집품을 계속 보유한다는 사실만 보고 부가 혜택이 이미 사용됐는지, 신청 기간이 지났는지까지 알 수는 없다.</p><p>따라서 토큰을 이전할 수 있더라도 최초 구매자와 나중의 수집가가 받는 묶음은 달라질 수 있다. 무엇이 아직 제공되지 않았는지, 사용 여부는 누가 기록하는지, 새 소유자는 누가 인정하는지가 실질적인 질문이다. 기획자가 설명한 Golden Ticket 재등록은 마지막 단계를 보여 준다. 블록체인 기록의 변경을 공연장에 도착한 사람을 받아들이는 서비스와 연결하는 일이다.</p><h2>약속은 화면 밖에서도 이행돼야 했다</h2><p>이렇게 보면 NFT Yourself는 음악에 토큰이라는 이름만 붙인 상품이 아니었다. 수집품과 다른 경로로 전달되는 혜택을 묶은 실험이었다. 레코드에는 배송지가, 공연 입장에는 조율이 필요했다. 오래 남는 질문은 토큰이 지갑에 도착했느냐보다 소유자가 그 기록에서 실제 약속된 경험으로 나아갈 수 있었느냐다. 여기서 다룬 것은 2021년에 발표·기록된 조건과 경험이며, 오래된 토큰에 지금도 미사용 혜택이 남아 있다는 뜻은 아니다.</p><h2>출처</h2><ul><li><a href="https://www.livenation.com/exclusives/185/kings-leon-team-up-yellowheart-present">Live Nation: NFT Yourself 출시와 상품별 혜택 발표</a></li><li><a href="https://www.vinylchapters.com/i-took-part-in-one-of-the-worlds-first-nft-album-sales/">제이미 파멘터: 직접 구매·교환 안내 경험</a></li><li><a href="https://news.pollstar.com/2021/04/25/nft-wtf-the-blockchain-revolution-breaks-through-in-music-ticketing/">Pollstar: YellowHeart·킹스 오브 리온 매니저 인터뷰</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>유니삭스 — 토큰을 양말로 바꾸는 순간</title>
    <link>https://coinyq.com/ko/stories/unisocks-token-redemption-real-socks</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/unisocks-token-redemption-real-socks</guid>
    <pubDate>Sat, 19 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[유니스왑의 2019년 굿즈 실험에는 독특한 선택이 있었다. 토큰을 계속 거래하거나, 토큰을 사용해 실제 양말을 주문하는 것이다. 이야기는 거래소에서 배송 주소로 넘어가는 순간에 선명해진다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/unisocks-token-redemption-real-socks.webp" alt="유니삭스 — 토큰을 양말로 바꾸는 순간" /></p><p>유니스왑의 2019년 굿즈 실험에는 독특한 선택이 있었다. 토큰을 계속 거래하거나, 토큰을 사용해 실제 양말을 주문하는 것이다. 이야기는 거래소에서 배송 주소로 넘어가는 순간에 선명해진다.</p><h2>정가표가 없는 굿즈</h2><p>보통 양말 한 켤레는 구매의 결과다. Uniswap Labs가 2019년 5월 시작한 실험에서는 아직 실현하지 않은 선택으로 남을 수도 있었다. 구매자는 실제 양말 한 켤레를 요청할 권리를 나타내는 SOCKS 토큰을 받았다. 그 권리를 보관하거나 거래하거나 사용할 수 있었다. 누군가 신기로 결정하기 전에도 굿즈의 교환권은 사람들 사이를 돌아다닐 수 있었다.</p><p>이 단계의 SOCKS는 서로 대체 가능한 잔액이었다. 특정 그림의 캐릭터를 가리키는 대신, 한 단위가 다른 한 단위와 같은 종류의 교환권을 나타냈다. 앱은 수량을 추적하고 보유자가 몇 개를 교환할지 고르게 했다. 일반적인 토큰 풀에서 거래할 수 있었던 이유다. 뒤의 주문 과정에서 제시한 보너스 NFT는 수집품이라는 별도의 역할을 맡았다.</p><p>원래 앱은 SOCKS 토큰 500개를 ETH와 함께 유니스왑 풀에 넣었다고 설명한다. 상점 주인이 정가를 붙이는 대신 매수와 매도에 따라 가격이 움직였다. 구매자는 특정 양말 소유자와 흥정하지 않고 풀에서 교환권을 구할 수 있고, 판매자는 토큰을 그 시장에 되팔 수 있었다. 처음 풀에 넣은 수량이 이후에도 언제나 그대로 판매 대기 중이라는 뜻은 아니다.</p><h2>다음 한 켤레의 가격이 달라지는 이유</h2><p>ETH로 구매하는 경우를 생각해 보자. 풀은 ETH를 받고 SOCKS를 내보내며, 다음 거래 가격을 계산할 때 쓰는 두 자산의 잔액이 달라진다. 유니스왑 V1의 거래 코드는 투입량과 양쪽 준비금에 거래 수수료를 반영해 받을 수량을 계산한다. 구매가 이어져 풀의 SOCKS가 줄면 다음 호가도 움직인다. SOCKS를 되팔면 교환 방향이 반대가 된다. 양말이 든 소포를 창고에 반품하는 과정은 아니다.</p><p>실물 교환에는 다른 동작을 쓴다. 원래 앱에서 판매는 거래소 함수를 호출하지만, 양말 신청은 SOCKS 토큰의 소각 함수를 호출한다. 판매하면 교환권이 시장으로 넘어가고, 소각하면 그 교환권이 소비된다. 거래된 토큰은 다시 살 수 있지만, 사용한 교환권으로 양말을 한 번 더 받을 수 없는 이유다. 풀에서 판매 가능한 수량과 전체 미사용 교환권 수량은 관련되어 있어도 같은 숫자가 아니다.</p><p>이 구분은 눈길을 끄는 가격 숫자보다 중요하다. 토큰 풀의 가격은 그 풀의 조건에서 이루어지는 교환을 설명한다. 양말을 만드는 비용이나 모든 보유자의 매입가, 모두가 한꺼번에 팔 때 받을 금액을 알려주는 숫자는 아니다. 이 실험에서는 거래 가능한 권리를 원하는 수요와 실제 물건을 원하는 수요가 함께 작용했다. 둘은 같을 필요가 없었다.</p><h2>주문하면 교환권이 사라진다</h2><p>2019년 10월 22일 공식 저장소에는 실물 교환 출시 커밋이 남았다. 화면은 교환할 SOCKS 수량을 묻고, 마지막 주문 단계 전에 배송 정보를 받았다. 구현은 선택한 수량의 소각 작업을 호출한 뒤 거래를 기다리고 완료 화면을 보여준다. 토큰을 사는 과정과 소포를 주문하는 과정은 따로 설계되어 있었다.</p><p>보유자에게 교환은 무엇을 남길지 고르는 일이었다. 사용하지 않은 교환권은 나중에 거래하거나 실물로 바꿀 선택을 남겼다. 교환을 신청하면 선택한 토큰을 실제 제품을 받는 데 사용했다. 코드는 이 선택을 지갑 속 그림의 변화가 아니라 상태의 변화로 드러냈다. 신을 수 있는 한 켤레를 선택하는 대신, 같은 교환권을 나중에 다시 쓸 가능성은 사라졌다.</p><h2>상자를 포장하는 것은 블록체인이 아니다</h2><p>보존된 배송 양식은 이름·우편 주소·국가·이메일을 요구했다. 지갑으로 주문 정보를 담은 메시지에 서명받아 웹 양식으로 제출했고, 소각 거래는 교환 화면의 별도 단계였다. 확인 뒤에는 지역에 따라 달라질 수 있는 2~3주의 예상 배송 기간을 표시했다. 이것은 앱의 안내였으며, 모든 소포가 그 기간에 도착했다는 증거는 아니다.</p><p>지갑도 두 가지 일을 따로 했다. 주문 메시지에 서명하는 것은 입력한 배송 정보를 지갑과 연결하는 일이었고, 소각 거래를 보내는 것은 이더리움의 토큰 잔액을 바꾸는 일이었다. 소스 코드에서 주소 양식은 웹 서비스로 제출되며 소각 호출의 내용으로 전달되지 않는다. 거래 가능한 온체인 교환권과 일반 배송 절차가 이렇게 만났다. 요청을 실제 배송으로 이어 주는 책임은 여전히 이행 서비스에 있었다.</p><p>장난스러워 보이는 실험은 이 지점에서 생각할 거리를 남긴다. 체인은 토큰을 사용한 기록을 남길 수 있지만, 양말은 여전히 사람과 배송망이 보내야 한다. 주문 확인이 수령 증명은 아니었다. 유니삭스는 실물 교환권을 쉽게 거래하게 만들면서, 약속을 이행하는 데 필요한 일상적인 노동도 드러냈다. 가장 흥미로운 순간은 가격 기록이 아니다. 가능성을 보관하던 사람이 실제 양말 한 켤레를 보내 달라고 결정하는 순간이다. 여기서 설명한 것은 보존된 당시 설계다. 오래된 토큰을 지금도 교환할 수 있다거나 특정 주문이 실제 배송됐다는 확인은 아니다.</p><h2>출처</h2><ul><li><a href="https://blog.uniswap.org/unification">2019년 5월 출시를 기록한 Uniswap 회고</a></li><li><a href="https://github.com/Uniswap/unisocks/blob/e7e07f51957f563855213fa9ab16dedcffcbbd46/src/components/Works.js">원래 앱의 SOCKS 작동 방식 설명</a></li><li><a href="https://github.com/Uniswap/unisocks/commit/d9ddfc743a11ebdd77dcc0f66d30da28a83b0123">실물 교환 출시 커밋</a></li><li><a href="https://github.com/Uniswap/unisocks/blob/e7e07f51957f563855213fa9ab16dedcffcbbd46/src/components/Redeem.js">원래 앱의 교환·배송 상태 구현</a></li><li><a href="https://github.com/Uniswap/unisocks/blob/e7e07f51957f563855213fa9ab16dedcffcbbd46/src/components/RedeemForm.js">원래 앱의 배송 주소 양식</a></li><li><a href="https://github.com/Uniswap/v1-contracts/blob/master/contracts/uniswap_exchange.vy">유니스왑 V1 거래 코드: 준비금에 따른 가격과 교환</a></li><li><a href="https://github.com/Uniswap/unisocks/blob/e7e07f51957f563855213fa9ab16dedcffcbbd46/src/pages/Main/index.js">원래 Unisocks 앱: 판매와 소각을 나눈 호출</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>크립토펑크: 소유자는 체인에, 그림은 어디에?</title>
    <link>https://coinyq.com/ko/stories/cryptopunks-ownership-image-onchain</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/cryptopunks-ownership-image-onchain</guid>
    <pubDate>Sun, 13 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[크립토펑크는 ERC-721이 나오기 전인 2017년, 픽셀 캐릭터 1만 개의 소유권을 기록했다. 그림 자체를 저장하는 일은 별개였고 2021년에 이루어졌다. NFT의 소유자·식별자·이미지를 나누어 살펴본다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/cryptopunks-ownership-image-onchain.webp" alt="크립토펑크: 소유자는 체인에, 그림은 어디에?" /></p><p>크립토펑크는 ERC-721이 나오기 전인 2017년, 픽셀 캐릭터 1만 개의 소유권을 기록했다. 그림 자체를 저장하는 일은 별개였고 2021년에 이루어졌다. NFT의 소유자·식별자·이미지를 나누어 살펴본다.</p><h2>복사할 수 있는 초상화</h2><p>크립토펑크 한 점은 가로세로 24픽셀 안에 들어갔다. 그림을 복사하는 일은 쉬웠다. 라바 랩스가 2017년 6월 컬렉션을 내놓았을 때 더 어려운 질문은 따로 있었다. 특정 이더리움 주소가 그 그림의 소유자라는 사실을 다른 사람도 확인하게 하려면 어떻게 해야 할까. 실험은 서로 다른 캐릭터 1만 개와 이들을 위해 만든 거래 시장에서 출발했다.</p><p>처음 공개 배포 때 라바 랩스에 지급하는 구입 대금은 없었다. 그래도 이더리움과 상호작용하려면 네트워크 수수료가 들었다. 핵심은 내려받은 파일이나 미술품 웹사이트의 일반 회원 계정이 아니었다. 특정 펑크를 주소에 연결한 계약 속 기록이었다. 같은 초상화를 다른 컴퓨터에 저장해도 그 기록은 바뀌지 않았다.</p><h2>얼굴 뒤에 있는 번호</h2><p>계약을 보면 이 차이가 구체적으로 드러난다. `punkIndexToAddress`는 펑크의 번호와 소유자 주소를 연결하고, `balanceOf`는 주소가 보유한 개수를 센다. 누군가 펑크 세 개를 갖고 있다는 정보와 어느 세 개를 갖고 있는지는 다른 정보다. 잔액을 세는 기능이 있어도 각 수집품의 정체성은 따로 필요했다.</p><p>거래 기능도 같은 시스템 안에 들어 있었다. 소유자는 특정 펑크를 매물로 내놓고, 구매자는 입찰할 수 있었다. 구매가 성립하면 그 번호에 연결된 주소가 바뀌었다. 웹사이트는 이런 동작을 쉽게 이용하게 해 주었지만, 소유권과 거래 규칙은 계약이 담당했다. 보기 좋은 갤러리 화면은 기록을 다루는 창구였으며, 기록 자체는 아니었다.</p><h2>공통 인터페이스보다 먼저 나온 NFT</h2><p>크립토펑크는 ERC-721 컬렉션으로 출시되지 않았다. 보관된 공식 FAQ는 일부 ERC-20식 잔액 조회 기능을 갖춘 자체 계약이라고 명시한다. 작성일이 2018년 1월 24일인 ERC-721 명세는 이후 크립토펑크를 기존 구현 사례에 포함했다. 고유한 자산의 소유권을 하나씩 추적하고, 서로 다른 소프트웨어가 이를 공통된 방식으로 다룰 필요가 있었다.</p><p>공통 인터페이스가 있으면 지갑이나 시장이 서로 다른 컬렉션에 같은 종류의 질문을 할 수 있다. ERC-721은 계약 주소와 토큰 식별자를 함께 사용하고, 소유권 조회와 이전 동작을 정의한다. 이는 호환성을 위한 진전이지, 앞서 나온 모든 프로젝트를 소급해 다시 작성한 일이 아니다. 크립토펑크는 필요성을 보여 준 사례였지만 원래의 시장 계약을 유지했다.</p><h2>지문에는 그림이 들어 있지 않다</h2><p>초기 설계에는 또 하나의 구분이 있었다. 계약의 `imageHash`에는 펑크들을 모은 전체 이미지의 암호학적 지문이 저장됐다. 파일을 가진 사람은 해시를 계산해 기록된 값과 비교할 수 있었다. 그 계약이 어떤 이미지를 가리키는지 확인하는 방법이었다.</p><p>하지만 지문은 백업이 아니다. 해시에는 초상화를 다시 그릴 수 있는 이미지 바이트가 들어 있지 않았다. 소유권 기록이 남아 있어도 사용자는 실제 그림을 다른 곳에서 구해야 할 수 있었다. 작품이 블록체인에 있다는 말에는 그래서 두 질문이 숨어 있다. 소유권은 어디에 기록되어 있으며, 눈으로 보는 내용은 어디에 저장되어 있는가.</p><p>2021년 8월 18일, 라바 랩스는 이미지와 속성 데이터를 담은 별도의 계약을 발표하며 두 번째 질문에 답했다. 이 계약에서는 펑크의 픽셀이나 SVG, 머리 모양·안경 같은 속성을 조회할 수 있었다. 팀은 작업을 독려한 커뮤니티 구성원 snowfro와 0xdeafbeef에게 공을 돌렸고, 0xdeafbeef의 개념 증명도 소개했다. 배포에 7,300만 gas가 넘게 들었다고 밝혔다. 이는 연산량의 단위이며 달러 금액이 아니다.</p><h2>무엇이 보존되었나</h2><p>발표에 따르면 이더리움 클라이언트로 이미지 조회 함수를 직접 읽을 때는 유료 트랜잭션을 제출할 필요가 없었다. 큰 비용이 든 쪽은 처음 데이터를 체인에 넣는 작업이었다. 추가된 계약 덕분에 소유권 이력과 함께 이미지도 이더리움에서 가져올 수 있게 됐다. 기존 시장을 새 토큰 표준으로 교체한 것은 아니었다.</p><p>ERC-721 자체가 모든 이미지를 온체인에 두도록 요구하지는 않는다. 선택적으로 구현하는 메타데이터 인터페이스는 URI를 가리킬 수 있고, 명세는 그 참조가 바뀔 수도 있다고 명시한다. 같은 소유권 표준을 따르는 두 컬렉션도 이미지 저장 방식은 크게 다를 수 있다. 호환성과 보존은 서로 다른 문제를 푼다.</p><p>크립토펑크의 역사는 그 차이를 보여 준다. 2017년에는 초상화를 복사해도 계약에 적힌 소유자가 되지 않았다. 2021년에는 이미지 데이터를 저장하면서 별도의 그림 파일을 찾아야 하는 의존을 줄였다. 이는 디지털 미술의 모든 요소를 한 번에 영구화한 사건보다, 수집가가 무엇을 검증하고 가져올 수 있는지를 차례로 결정한 과정에 가깝다.</p><h2>초상화 한 점의 기록을 따라가 보면</h2><p>서로 다른 두 사이트가 똑같은 펑크 그림을 보여 준다고 해 보자. 그림만으로는 각 사이트가 어느 계약을 읽는지 알 수 없다. ERC-721 토큰은 계약 주소와 토큰 ID를 함께 봐야 특정할 수 있다. 이름이나 이미지가 같다는 것만으로는 부족하다. 자체 계약을 쓰는 크립토펑크에서도 실질적인 질문은 같다. 이 화면 뒤에는 어느 시장 계약의 몇 번 펑크가 있는가?</p><p>그다음 기록들은 서로 다른 질문에 답한다. 원래 시장 계약은 펑크 번호를 소유자 주소에 연결한다. 2021년에 발표된 이미지 데이터 계약은 그 번호의 픽셀과 속성을 돌려준다. 소유자를 조회하는 일만으로 그림을 가져오지는 못하고, 그림을 가져온다고 소유자가 바뀌지도 않는다. 둘 다 구매 없이 살펴볼 수 있다. 번호에서 소유 기록으로, 다시 표시되는 데이터로 이어지는 길을 따라가면 이 컬렉션을 구체적으로 이해할 수 있다.</p><p>선택적 메타데이터 기능을 쓰는 ERC-721 컬렉션에서는 두 번째 길에 단계가 더 있을 수 있다. 토큰의 URI가 JSON 설명 문서를 가리키고, 그 안의 image 항목이 다시 이미지 주소를 가리키는 식이다. 웹사이트·설명 문서·그림 파일이 서로 다른 주소에 있을 수 있다는 뜻이다. 눈에 보이는 썸네일은 이 조회 과정의 끝에 있다. 표준을 따른다는 사실만으로 그 길의 모든 부분을 누가 계속 유지할지까지 알 수는 없다.</p><h2>출처</h2><ul><li><a href="https://www.larvalabs.com/cryptopunks">라바 랩스: 크립토펑크 프로젝트 역사</a></li><li><a href="https://raw.githubusercontent.com/larvalabs/cryptopunks/master/contracts/CryptoPunksMarket.sol">CryptoPunksMarket 계약 소스 코드</a></li><li><a href="https://eips.ethereum.org/EIPS/eip-721">ERC-721: 대체불가토큰 표준</a></li><li><a href="https://www.larvalabs.com/writing/2021-8-18-18-0/on-chain-cryptopunks">온체인 크립토펑크 발표</a></li><li><a href="https://www.larvalabs.com/cryptopunks/index">보관된 크립토펑크 시장과 FAQ</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>비트코인 타임록 — 열쇠가 있어도 기다려야 하는 이유</title>
    <link>https://coinyq.com/ko/stories/bitcoin-timelocks-key-must-wait</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/bitcoin-timelocks-key-must-wait</guid>
    <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[비트코인은 서명뿐 아니라 기다림도 요구할 수 있다. BIP65와 BIP112는 나중에 쓸 수 있는 출구를 지출 조건에 넣는 방법, 그리고 기한이 되어도 돈이 저절로 움직이지 않는 이유를 보여 준다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/bitcoin-timelocks-key-must-wait.webp" alt="비트코인 타임록 — 열쇠가 있어도 기다려야 하는 이유" /></p><p>비트코인은 서명뿐 아니라 기다림도 요구할 수 있다. BIP65와 BIP112는 나중에 쓸 수 있는 출구를 지출 조건에 넣는 방법, 그리고 기한이 되어도 돈이 저절로 움직이지 않는 이유를 보여 준다.</p><h2>예약된 거래만으로는 부족했다</h2><p>비트코인 지갑 이야기에서 결정적인 것은 대개 열쇠를 가졌느냐다. BIP65는 여기에 질문 하나를 더한다. 아직 쓸 때가 되지 않은 것은 아닐까? 피터 토드가 2014년 10월 1일 제안한 CHECKLOCKTIMEVERIFY는 특정 시각이나 블록 높이에 도달해야 지출 경로를 사용할 수 있게 하는 규칙이다. 이후 Bitcoin Core 0.11.2에 이 규칙을 집행하는 기능이 포함됐다. 해당 버전을 설치하는 것과 합의 규칙이 활성화되는 것은 별개였다.</p><p>비트코인에는 이미 특정 거래가 블록에 들어갈 수 있는 때를 늦추는 nLockTime 필드가 있었다. 그러나 거래 하나를 미뤘다고 그 돈이 먼저 움직일 수 없다는 보장이 생기지는 않았다. 같은 출력을 쓰는 다른 거래에 서명할 수 있는 사람은 기다림을 빼버릴 수도 있었다. BIP65는 조건을 출력을 지키는 스크립트에 넣었다. 그 경로로 지출하려는 거래라면 스스로 기다리겠다고 선택하는 수준을 넘어 정해진 시간 조건을 충족해야 했다.</p><h2>나중에 열리는 출구</h2><p>제안서의 예를 보면 차이가 분명해진다. 평소에는 사용자와 서비스 양쪽의 서명이 필요한 지갑을 생각해 보자. 두 번째 경로는 사용자 서명만 요구하되 정해진 기한 뒤에 열리도록 만들 수 있다. 이는 BIP의 설계 예시이지 모든 지갑에 이런 복구 기능이 있다는 뜻은 아니다. 기한 전에는 사용자가 혼자 이 경로를 쓸 수 없지만, 기한 뒤에는 서비스가 응답하지 않아도 자금이 계속 묶일 필요가 없다.</p><p>타임록은 시간이 되면 송금을 전파하는 알람이 아니다. 해당 서명과 출력을 실제로 지출하는 거래가 여전히 필요하다. 늦게 열리는 경로가 생겼다고 협력 경로가 자동으로 닫히지도 않는다. 예시에서는 출력이 아직 지출되지 않았다면 기한 뒤에도 사용자와 서비스가 함께 지출할 수 있다. 달라지는 것은 허용되는 행동이지 반드시 일어날 행동이 아니다.</p><h2>시계는 언제부터 움직일까</h2><p>절대적인 기준점이 항상 적합한 시계는 아니다. BtcDrak, 마크 프리덴바흐, 에릭 롬브로조가 2015년 8월 제안한 BIP112는 CHECKSEQUENCEVERIFY를 설명한다. BIP68과 함께 쓰면 출력이 일정한 나이에 이를 때까지 기다리게 할 수 있다. 제안서의 에스크로 예시는 자금을 넣는 거래가 확정된 때부터 시간을 센다. 입금 전부터 계속 다가오는 고정된 날짜를 정하는 것과 다르다.</p><p>여기서 시계는 비트코인의 규칙으로 정의된다. 블록 개수를 셀 수도 있고, 시간 기준 타임록은 휴대전화 시계가 아니라 BIP113의 최근 블록 타임스탬프 중앙값 같은 블록체인 시간 규칙을 따른다. BIP112는 채널의 상대방이 오래된 약정에 대응할 시간을 지연으로 확보하는 방법도 설명한다. 기다림의 목적은 돈을 얼리는 데 그치지 않는다. 상대에게 행동할 시간을 주거나 나중의 출구를 남기면서도, 그 출구를 쓸 사람은 여전히 서명으로 가린다.</p><h2>출처</h2><ul><li><a href="https://bips.dev/65/">BIP65: 절대 타임록의 동기와 지갑 예시</a></li><li><a href="https://bitcoincore.org/en/releases/0.11.2/">Bitcoin Core 0.11.2: BIP65 지원과 활성화</a></li><li><a href="https://bips.dev/112/">BIP112: 상대 타임록·에스크로·결제 채널</a></li><li><a href="https://bips.dev/113/">BIP113: 타임록 계산에 쓰는 과거 시간 중앙값</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>세계은행 bond-i — 채권의 주인이 바뀌면 장부도 함께</title>
    <link>https://coinyq.com/ko/stories/world-bank-bondi-shared-bond-register</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/world-bank-bondi-shared-bond-register</guid>
    <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[2018년 세계은행과 CBA는 호주달러 채권을 사설 블록체인 플랫폼에 올렸다. 발행 뒤 거래와 상환까지 이어진 실험은 공동 장부의 가능성과, 다른 참여자도 재사용할 시장 기반을 만드는 숙제를 함께 보여 준다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/world-bank-bondi-shared-bond-register.webp" alt="세계은행 bond-i — 채권의 주인이 바뀌면 장부도 함께" /></p><p>2018년 세계은행과 CBA는 호주달러 채권을 사설 블록체인 플랫폼에 올렸다. 발행 뒤 거래와 상환까지 이어진 실험은 공동 장부의 가능성과, 다른 참여자도 재사용할 시장 기반을 만드는 숙제를 함께 보여 준다.</p><h2>익숙한 채권, 달라진 장부</h2><p>2018년 8월 24일, 호주 커먼웰스은행(CBA)은 세계은행의 bond-i가 1억1,000만 호주달러를 조달했다고 발표했다. 조건은 익숙했다. 호주달러로 표시된 2년 만기 채권에 이자 지급과 만기일이 있었다. 결제 예정일은 8월 28일이었다. 달라진 것은 기록을 관리하는 플랫폼이었다. 블록체인 채권도 채권이었다. 장부를 바꿨다고 투자 대상이 이더가 되지는 않았다.</p><p>앞선 CBA 발표는 워싱턴의 세계은행과 시드니의 CBA가 운영하는 사설 이더리움 블록체인이라고 명시했다. 이 구분은 중요하다. 이더리움 기술을 쓴다는 것이 공개 이더리움 네트워크에 채권을 등록한다는 뜻은 아니었다. 확인된 기관들이 공동 시스템에 참여했다. 핵심 질문은 채권의 생애가 이어지는 동안 참여자들이 어떻게 합의된 기록을 함께 사용할 수 있느냐였다.</p><h2>두 번째 소유자가 중요하다</h2><p>출시가 잘됐다고 채권에 필요한 모든 기능을 시험한 것은 아니다. 한 투자자가 다른 투자자에게 팔면 기록도 새 소유자를 따라가야 한다. 2019년 5월 CBA는 세계은행, 시장조성자 TD증권과 함께 개발한 기능으로 유통시장 거래를 마치고 이를 분산원장에 기록했다고 발표했다. 발행 때 누가 채권을 받았는지 남기는 실험이 이후의 매매까지 넘어간 것이다.</p><p>2019년 8월에는 같은 채권을 추가 발행해 5,000만 호주달러를 더 조달했다. CBA, RBC캐피털마켓, TD증권이 공동 주관했다. 더 많은 자금과 참여자가 플랫폼을 이용해야 하는 또 하나의 실제 시험이었다. CBA는 결제·보관·규제 준수의 효율을 높이는 작업도 앞으로의 과제로 언급했다. 거래 기록 기능이 작동했다는 근거가 주변의 모든 절차가 사라졌다는 증거는 아니었다.</p><h2>실험이 끝난 뒤에도 시장은 돌아가야 한다</h2><p>2023년 세계은행 회고는 2018~2020년 이 호주달러 채권의 발행·관리·상환이 성공적으로 이뤄졌다고 설명했다. 동시에 더 넓은 장애물도 짚었다. 이런 실험에는 시간과 돈이 많이 드는 일회성 플랫폼이 필요한 경우가 많았다. 거래 한 건을 성사시키는 것과 손쉽게 재사용할 시장 시스템을 만드는 것은 다른 성과였다.</p><p>bond-i가 단순히 “블록체인 위의 채권”이라는 표현보다 흥미로운 이유가 여기에 있다. 출시, 이후의 거래, 추가 발행은 한 금융상품의 여러 단계를 따라 학습한 프로젝트를 보여 준다. 남은 질문은 다음 발행기관과 다음 투자자가 전체 구성을 새로 만들지 않고도 비슷한 기반을 쓸 수 있느냐였다. 장부를 공유하는 일은 그 작업의 시작이었다.</p><h2>출처</h2><ul><li><a href="https://www.commbank.com.au/guidance/newsroom/cba-helps-world-bank-raise-a-110-million-with-launch-of--bond-i--201808.html">CBA의 2018년 8월 24일 출시 발표와 채권 조건</a></li><li><a href="https://www.commbank.com.au/guidance/newsroom/cba-picked-by-world-bank-to-deliver-world-s-first-standalone-blo0-201808.html">CBA 주관사 선정 발표: 사설 이더리움과 운영기관</a></li><li><a href="https://www.commbank.com.au/guidance/newsroom/world-bank-and-cba-blockchain-bond-201905.html">CBA: 2019년 5월 블록체인에 기록한 유통시장 거래</a></li><li><a href="https://www.commbank.com.au/guidance/newsroom/world-bank-blockchain-bond-bond-i-201908.html">CBA: 2019년 8월 추가 발행과 후속 개발 과제</a></li><li><a href="https://projects.worldbank.org/en/about/unit/treasury/impact/digitalization-and-bond-market-efficiencies">세계은행 회고: 채권 관리·상환과 재사용할 기반</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>뱅코르(Bancor): 396,720 ETH가 모인 판매와 웹사이트 장애</title>
    <link>https://coinyq.com/ko/stories/bancor-150m-ico-ethereum-congestion-first-amm</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/bancor-150m-ico-ethereum-congestion-first-amm</guid>
    <pubDate>Mon, 24 Aug 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[뱅코르는 2017년 토큰 판매에서 396,720 ETH를 모았다고 보고했고, 웹사이트와 앱 장애로 판매 시간을 연장했습니다. 준비금 기반 AMM의 설계와 이후 드러난 BNT 동결 권한은 이더리움 전체가 멈췄다는 이야기와 구분해야 합니다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/bancor-150m-ico-ethereum-congestion-first-amm.webp" alt="뱅코르(Bancor): 396,720 ETH가 모인 판매와 웹사이트 장애" /></p><p>뱅코르는 2017년 토큰 판매에서 396,720 ETH를 모았다고 보고했고, 웹사이트와 앱 장애로 판매 시간을 연장했습니다. 준비금 기반 AMM의 설계와 이후 드러난 BNT 동결 권한은 이더리움 전체가 멈췄다는 이야기와 구분해야 합니다.</p><h2>1. 유통된 적 없는 화폐에서 따온 이름</h2><p>1940~1942년 존 메이너드 케인스와 E. F. 슈마허는 국제청산동맹 결제용 초국가 계산 단위로 미유통 화폐 &apos;뱅코르&apos;를 구상했습니다. 프랑스어 &apos;banque or&apos;(은행 금)에서 유래한 영국의 브레턴우즈 제안은 채택되지 못해 종이에만 남았습니다.</p><p>뱅코르 프로토콜은 존 메이너드 케인스가 1944년 브레턴우즈 회의에서 제안했던, 국제 무역을 기록하고 균형을 맞추기 위한 초국가적 통화 단위를 기리기 위해 명명되었습니다.</p><p>2017년 4월 28일 초안 v0.77 뒤 6월 6일 초안 v1.00이 나왔습니다. 에얄 헤르조그, 가이 베나르치, 갈리아 베나르치가 작성하고 스콧 모리스와 베르나르 리에타에르가 기여했습니다. 법원 서류상 이스라엘 창업자들은 뱅코르를 &apos;본질적으로 거래 가능한 통화의 글로벌 표준&apos;으로 만들고자 스위스 비영리 Bprotocol Foundation 산하에서 구축했습니다.</p><p>백서 설계상 스마트 토큰은 자체 계약에 타 토큰 준비금을 보유해 직접 매수(발행)·청산(소각)되었습니다. 백서는 &apos;스마트 토큰이 유동성을 얻기 위해 거래소에 상장될 필요가 없다&apos;며 미상장 통화의 전환성을 약속했습니다.</p><h2>2. 뱅코르가 보고한 39만 6,720 ETH와 마비된 웹사이트</h2><p>2017년 6월 12일 뱅코르 세일에서 10,885명이 396,720 ETH(자체 발표 약 1억 5,000만 달러, 사이트 약 1억 5,300만 달러)를 기여해 The DAO의 1억 5,200만 달러를 넘겼습니다.</p><p>달러액은 시세에 따랐습니다. 파이낸스 매그네이츠는 360달러 기준 396,619 ETH를 1억 4,200만 달러 초과로 집계했고 1억 5,300만 달러는 이후 고점 기준입니다. 이는 수령한 판매 수익금이며 기업 가치가 아니었습니다.</p><p>혼란은 뱅코르 웹사이트에서 일어났습니다. 판매 기간은 팀이 &apos;압도적인 수요와 트래픽, 대규모 악의적 공격&apos;이라 부른 사태로 1시간에서 3시간으로 늘어났습니다. 구매자들은 오류를 겪었고, 당시 기록에 이더리움 중단 언급은 없으며 문제는 스타트업 인프라였습니다.</p><p>뱅코르는 79,323,978 BNT를 생성해 약 절반을 공모 판매했고(한 구매자 2,700만 달러 매수 보고), 백서에 따라 20%를 가격 공식 담보인 이더(ETH) 준비금으로 배정했습니다.</p><h2>3. 오더북 대신 준비금과 비율을 택한 수학 공식</h2><p>스마트 토큰 가격은 준비금 잔액을 발행량과 생성 시 고정되는 준비금 비율(CRR)의 곱으로 나눈 값입니다. CRR이 100% 미만일 때 매수는 준비금과 발행량을 늘리며 가격을 올리고, 매도는 토큰을 소각하고 준비금을 지급하며 가격을 내립니다. 오더북 없이 공식 자체가 시장이었습니다.</p><p>토큰 간 거래는 백서상 &apos;토큰 체인저&apos; 계약을 통했습니다. 총 100% CRR로 둘 이상의 준비금을 보유하며 차익거래로 균형을 맞췄습니다. 허브는 단일 이더(ETH) 준비금을 보유하며 &apos;뱅코르 프로토콜로 배포된 최초의 스마트 토큰&apos;인 BNT였습니다.</p><p>백서 요약은 이 계약들을 &apos;자동화된 마켓 메이커로 기능한다&apos;고 기술했습니다. 인간 없이 고정 규칙 계약이 가격을 제시한다는 프로젝트의 설명입니다. 문서는 2017년 봄 발표된 공식 기반 유동성 프로토콜을 뒷받침하지만, 뱅코르가 최초 AMM이거나 후속 설계에 영향을 줬다는 주장은 뒷받침하지 않습니다.</p><p>유니스왑 v1 백서는 ETH와 토큰 준비금의 곱을 스왑 중 일정하게 유지한다고 설명합니다. 스왑은 CRR에 맞춰 거래 자산을 발행·소각하지 않고 ETH-토큰 풀의 두 잔고를 바꿉니다. 뱅코르는 준비금 비율과 공급량, 유니스왑은 x·y = k인 풀 잔고로 가격을 정했습니다.</p><h2>4. 업그레이드 지갑 침해와 BNT 동결 권한의 노출</h2><p>2018년 7월 뱅코르에서 약 2,350만 달러(이더(ETH) 1,250만 달러, NPXS 100만 달러, BNT 1,000만 달러)가 유출되었습니다(테크크런치 보도). 침투 지점은 가격 공식이 아닌 권한 지갑이었습니다.</p><p>스마트 계약 일부를 업그레이드하는 데 사용되던 지갑이 침해당했습니다.</p><p>뱅코르는 도난 BNT는 동결했으나 이더(ETH)나 NPXS는 동결하지 못했고 거래소를 중단했습니다. 이는 자체 토큰에 개입할 수 있음을 보여줬으며, 찰리 리는 직후 그 통제력을 비판했습니다.</p><p>고객의 자금을 잃을 수 있거나 고객의 자금을 동결할 수 있다면 그 거래소는 탈중앙화된 것이 아닙니다. 뱅코르는 둘 다 할 수 있습니다. 그것은 탈중앙화라는 잘못된 착각입니다.</p><p>2020년 6월 18일, 뱅코르는 6월 16일 배포된 BancorNetwork v0.6 계약 취약점을 공개했습니다. 최근 3개 버전 버그로 이용자가 무제한 승인을 내준 상태였고, 1인치는 &apos;누구나 이 승인으로 사용자 자금을 탈취할 수 있는 공개 메서드&apos;를 지목했습니다. 뱅코르는 자산 보호용 통제된 익스플로잇을 실행했다고 밝혔으며(프로젝트 설명), 보도상 일부 사용자 손실도 발생했습니다.</p><h2>5. 뱅코르·유니스왑의 설계 차이와 증거개시 요청</h2><p>유니스왑 v1 백서는 ETH와 ERC-20 준비금을 둔 계약이 x·y = k를 유지하며 스왑 가격을 정한다고 설명합니다. 뱅코르는 준비금 비율에 따라 토큰을 발행·소각했고, 유니스왑은 풀의 두 잔고를 바꿨습니다.</p><p>비교한 1차 문서는 기술 차이만 뒷받침할 뿐, 뱅코르가 유니스왑에 영향을 줬거나 후계 관계였음을 입증하지 않습니다. 따라서 서술도 계보가 아닌 설계 비교에 한정합니다.</p><p>텍사스 연방법원 소송에 적시된 타임라인은 2017년 v1, 2020년 4월 v2, &apos;비영구적 손실 보호&apos;를 도입한 2020년 10월 v2.1, 2022년 5월 11일 v3입니다. 소장은 2022년 6월 19일 인출 급증으로 보호가 중단되어, v3에서 보호된다고 홍보된 투자자들이 손실에 노출되었다고 주장합니다.</p><p>2023년 5월 집단소송이 제기됐고, 2024년 9월 6일 로버트 피트먼 판사는 대인관할권 부재와 미국 내 거래 주장 미비로 재단·LocalCoin·창업자들에 대한 청구를 본안 판단 없이 각하했습니다. 원고가 2025년 5월 27일 제출한 신청서에 따르면, 법원은 불복 신청을 하지 않았던 뱅코르 DAO를 피고로 복귀시켰고 서기는 DAO에 대해 궐석을 기재했습니다. 원고는 관할권, 미국 내 거래, 집단 인증과 손해액을 위한 증거개시를 요청한 뒤 궐석판결 신청을 검토하겠다고 밝혔습니다. 이 신청서는 당사자 주장이지 궐석판결이나 본안·사기 판결이 아닙니다.</p><h2>출처</h2><ul><li><a href="https://resources.bancor.network/pages/BancorProtocolWhitepaper.pdf">뱅코르 프로토콜 백서 (초안 v0.77, 2017년 4월 28일)</a></li><li><a href="https://bernard-lietaer.org/wp-content/uploads/2024/12/Bancor-Whitepaper-V1.0-1.pdf">뱅코르 백서 (초안 버전 1.00, 2017년 6월 6일)</a></li><li><a href="https://en.wikipedia.org/wiki/Bancor">뱅코르 — 케인스가 제안한 초국가적 통화</a></li><li><a href="https://siliconangle.com/2017/06/13/bancor-sets-initial-coin-offering-record-raising-150-million/">뱅코르, 1억 5천만 달러 이상 모금하며 ICO 기록 경신</a></li><li><a href="https://www.financemagnates.com/cryptocurrency/news/bancor-crowdsale-raises-140-million-less-three-hours/">뱅코르 크라우드세일, 3시간 미만에 1억 4천만 달러 이상 모금</a></li><li><a href="https://techcrunch.com/2018/07/10/bancor-loses-23-5m/">암호화폐 업계 최신 해킹으로 뱅코르 2,350만 달러 손실</a></li><li><a href="https://blog.1inch.com/bancor-network-hack-2020/">2020년 뱅코르 네트워크 해킹 사후 분석</a></li><li><a href="https://www.financemagnates.com/cryptocurrency/news/bancor-users-report-fund-loss-after-vulnerability-discovery/">취약점 발견 후 뱅코르 사용자 자금 손실 보고</a></li><li><a href="https://www.govinfo.gov/content/pkg/USCOURTS-txwd-1_23-cv-00533/pdf/USCOURTS-txwd-1_23-cv-00533-1.pdf">보고서 및 권고안 채택 명령, Basic v. BProtocol Foundation, No. 1:23-CV-533-RP (W.D. Tex.)</a></li><li><a href="https://app.midpage.ai/document/basic-v-bprotocol-foundation-1000407252780">보고서 및 권고안, Basic v. BProtocol Foundation, No. 1:23-cv-00533 (W.D. Tex.)</a></li><li><a href="https://cdn.prod.website-files.com/63c177fd300aebf674381b3f/687e59cc42a1b6a4a710958f_ECF%2081%20-%20Motion%20for%20Leave%20to%20Conduct%20Discovery.pdf">원고 측 증거개시 허가 신청서, Basic v. BProtocol Foundation, ECF No. 81</a></li><li><a href="https://hackmd.io/@HaydenAdams/HJ9jLsfTz">유니스왑 v1 백서</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>EIP-712 — 서명 버튼 앞에 읽을 내용을 놓다</title>
    <link>https://coinyq.com/ko/stories/eip712-readable-message-signing</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/eip712-readable-message-signing</guid>
    <pubDate>Thu, 24 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[지갑이 개인키를 지켜도 사용자는 자신이 무엇에 서명하는지 모를 수 있다. EIP-712는 메시지에 읽을 수 있는 구조를 주었다. 그 서명으로 어떤 권한을 줄지는 여전히 앱이 정한다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/eip712-readable-message-signing.webp" alt="EIP-712 — 서명 버튼 앞에 읽을 내용을 놓다" /></p><p>지갑이 개인키를 지켜도 사용자는 자신이 무엇에 서명하는지 모를 수 있다. EIP-712는 메시지에 읽을 수 있는 구조를 주었다. 그 서명으로 어떤 권한을 줄지는 여전히 앱이 정한다.</p><h2>키는 서명할 수 있어도 사람은 읽지 못했다</h2><p>2017년 9월 12일, 렘코 블루먼·레오니트 로그비노프·제이컵 에번스가 EIP-712를 제안했다. 출발점은 일상적인 불편이었다. 지갑은 긴 16진수 문자열을 보여 주며 서명을 요청할 수 있었다. 암호 기술이 제대로 작동해도 소유자는 그 안에 무엇이 있는지 알기 어려웠다. 제안은 데이터 항목마다 이름과 자료형을 붙여, 지갑이 요청의 내용을 보여 줄 수 있도록 했다.</p><p>겉모양만 바꾸는 일은 아니었다. 보내는 사람, 받는 사람, 수량을 뜻 모를 바이트 묶음 대신 서로 다른 항목으로 다룰 수 있었다. 명세는 앱 이름·버전·체인 식별자·검증 계약 주소 중 필요한 항목으로 서명 도메인도 정의했다. 내용이 같아 보여도 사용 맥락이 다르면 서명 결과가 달라지게 하는 장치다. 이 정보는 맥락을 구분하며, 사업자의 정직함을 인증하지는 않는다.</p><h2>항목 이름도 판단의 일부가 된다</h2><p>MetaMask 개발 문서는 화면에서의 의미를 짚는다. eth_signTypedData_v4는 구조화된 데이터를 확인할 수 있게 표시하며, 개발자에게 최상위 자료형 이름·도메인 이름·항목 이름을 보안 인터페이스의 일부로 다루라고 안내한다. 기술적으로 올바른 요청도 항목명이 모호하면 사람이 판단하기 어렵다. 구조가 설명할 자리를 만들었다면, 지갑과 앱은 그 자리를 잘 채워야 한다.</p><p>따라서 읽기 쉬워졌다는 것은 우선 무엇에 서명하는지 살펴볼 수 있다는 뜻이다. 그것이 로그인인지, 주문인지, 토큰 사용 권한인지는 메시지를 받아들이는 앱에 달려 있다. 메시지 표현과 앱의 동작을 구분해 읽으면 나오는 설계상의 해석이다. 가지런한 확인 화면 자체가 승인해도 좋다는 추천은 아니다.</p><h2>권한은 거래보다 먼저 건너갈 수 있다</h2><p>2020년 4월 13일 작성된 ERC-2612는 구체적인 사례다. permit 메시지에는 소유자, 사용 권한을 받을 주소, 한도, nonce, 제출 기한이 들어간다. 유효하게 제출되면 해당 주소의 사용 한도가 지정값으로 설정되고 nonce가 증가한다. 제출은 누구나 할 수 있어 소유자가 승인 거래를 직접 보낼 필요가 없다. 서명 자체가 토큰을 보내는 것은 아니지만, 설정된 한도는 이후 transferFrom을 통한 이동을 가능하게 할 수 있다.</p><p>nonce는 사용이 끝난 permit이 다시 성공하는 것을 막는다. 기한은 제출할 수 있는 시간을 제한하며, 이미 설정된 사용 한도를 자동으로 만료시키지는 않는다. permit이 효력을 내려면 누군가는 온체인 거래를 제출해야 한다. EIP-712는 반복 사용 처리를 앱의 몫으로 명시했다. 서명 요청을 읽는다는 것은 항목뿐 아니라 그것을 받은 계약이 수행할 동작까지 살펴보는 일이다. 버튼의 크기는 그대로여도 그 앞의 판단은 더 잘 보이게 됐다.</p><h2>출처</h2><ul><li><a href="https://eips.ethereum.org/EIPS/eip-712">EIP-712: 제안 이유·도메인 구분·반복 사용 처리의 경계</a></li><li><a href="https://docs.metamask.io/metamask-connect/evm/guides/sign-data/">MetaMask: 구조화된 서명과 사용자 보안 인터페이스</a></li><li><a href="https://eips.ethereum.org/EIPS/eip-2612">ERC-2612: 사용 한도·nonce·기한·제출 조건</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>MIT 디지털 졸업장 — 학교 밖에서도 확인할 수 있는 기록</title>
    <link>https://coinyq.com/ko/stories/mit-blockcerts-digital-diploma-verification</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/mit-blockcerts-digital-diploma-verification</guid>
    <pubDate>Thu, 24 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[2017년 MIT는 일부 졸업생에게 휴대전화에 보관하고 다른 사람에게 검증을 맡길 수 있는 졸업장을 제공했다. Blockcerts는 기록이 이동하는 방식을 바꾸면서도 누가 발급했는지라는 질문을 남겼다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/mit-blockcerts-digital-diploma-verification.webp" alt="MIT 디지털 졸업장 — 학교 밖에서도 확인할 수 있는 기록" /></p><p>2017년 MIT는 일부 졸업생에게 휴대전화에 보관하고 다른 사람에게 검증을 맡길 수 있는 졸업장을 제공했다. Blockcerts는 기록이 이동하는 방식을 바꾸면서도 누가 발급했는지라는 질문을 남겼다.</p><h2>졸업생이 직접 가지고 갈 수 있는 기록</h2><p>2017년 여름, MIT 졸업생 111명으로 구성된 집단에게 종이 졸업장과 함께 새로운 선택지가 생겼다. Blockcerts Wallet으로 이용하는 디지털 졸업장이었다. 학적 담당 부서는 Learning Machine과 시범 사업을 진행했다. MIT의 10월 17일 소개 글은 금융 전공과 미디어 예술·과학 전공 졸업생 두 집단을 참여 대상으로 설명했다. 대학이 주는 자격증명이라는 점은 익숙했지만, 다음 사람에게 보여 주는 경로가 달라지고 있었다.</p><p>MIT 미디어랩과 Learning Machine은 2016년 공개 소프트웨어 도구 Blockcerts를 개발했다. 졸업장 발급 과정에서는 학생의 앱이 키를 만들고, MIT가 공개키를 기록에 넣은 뒤 JSON 파일을 이메일로 보냈다. 졸업생은 파일이나 링크를 공유하고, 받은 사람은 매번 학적 담당 부서에 문의하지 않고 포털에서 검증할 수 있었다. 졸업장 내용 자체가 비트코인에 올라가는 것은 아니었다.</p><h2>작은 증명이 더 큰 기록과 이어진다</h2><p>Blockcerts 발급 소프트웨어 문서는 여러 증명서를 하나의 블록체인 기록에 연결하는 방식을 설명한다. 각 증명서의 해시를 구한 뒤 머클 트리로 묶는다. 루트는 묶음 전체를 요약하고, 개별 증명서에는 자기 해시에서 그 루트로 이어지는 경로의 증명이 포함된다. 검증자는 학생들의 기록을 전부 받지 않고도 그 관계를 다시 계산할 수 있다.</p><p>이 구조에서는 문서를 가지고 있는 것과 증거를 공개하는 것이 분리된다. 졸업생에게는 실제 증명서 파일이 필요하다. 체인에 남은 짧은 기록은 졸업장을 내려받아 복구할 수 있는 백업이 아니다. 해시와 경로를 대조하면 제시된 내용이 기록된 내용과 일치하는지 확인할 수 있다. 그렇다고 블록체인이 학생의 수강·이수 여부를 아는 심사자가 되는 것은 아니다.</p><h2>발급한 학교는 여전히 중요하다</h2><p>프로젝트의 검증 절차 문서는 해시 일치보다 더 많은 것을 확인한다. 발급에 쓴 키가 발급기관의 공개 정보에 있는지, 발급 당시 유효했는지 대조한다. 자격증명이 취소됐는지, 만료일이 있다면 지났는지도 확인한다. 그 발급기관 정보가 실제 어느 기관을 가리키는지 판단하는 신뢰 문제는 별도로 남는다. 내용이 바뀌지 않은 파일이라도 발급자를 모르면 곧바로 MIT 학위가 되지는 않는다.</p><p>MIT 학적 담당 부서의 안내에는 수령자의 구체적인 책임도 남아 있다. 이메일로 받은 졸업장 파일은 중요한 자료와 함께 보관하고, 지갑 복구용 암호문구도 지켜야 한다. 암호문구를 잃으면 지갑을 새로 설정하고 MIT에 재발급을 요청해야 할 수 있다고 설명한다. 독립성의 범위를 보여 주는 대목이다. 졸업생이 기록을 보관하고 제시할 수 있어도, 발급 책임은 학교에 있다. 기관의 자격증명을 더 잘 휴대하고 확인하게 된 것이지, 학위가 발급기관에서 떨어져 나온 것은 아니다.</p><h2>출처</h2><ul><li><a href="https://news.mit.edu/2017/mit-debuts-secure-digital-diploma-using-bitcoin-blockchain-technology-1017">MIT News 2017-10-17: 시범 사업과 발급 과정</a></li><li><a href="https://github.com/blockchain-certificates/cert-issuer">Blockcerts 발급 도구: 묶음·머클 증명·증명서 해시</a></li><li><a href="https://github.com/blockchain-certificates/cert-verifier-js/blob/master/docs/verification-process.md">Blockcerts 검증 절차: 발급키·취소·만료</a></li><li><a href="https://registrar.mit.edu/transcripts-records/diplomas/digital-diplomas">MIT 학적 안내: 디지털 졸업장 수령·보관·복구</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>BIP39 — 지갑을 되살리는 단어의 정체</title>
    <link>https://coinyq.com/ko/stories/bip39-wallet-backup-words</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/bip39-wallet-backup-words</guid>
    <pubDate>Wed, 23 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[장치가 고장 나도 지갑까지 잃는 것은 아니다. BIP39는 컴퓨터가 만든 난수를 순서 있는 단어 목록으로 바꿨다. 다만 익숙한 단어를 알아보는 것과 원래 지갑을 복원하는 것은 다른 문제다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/bip39-wallet-backup-words.webp" alt="BIP39 — 지갑을 되살리는 단어의 정체" /></p><p>장치가 고장 나도 지갑까지 잃는 것은 아니다. BIP39는 컴퓨터가 만든 난수를 순서 있는 단어 목록으로 바꿨다. 다만 익숙한 단어를 알아보는 것과 원래 지갑을 복원하는 것은 다른 문제다.</p><h2>장치는 바꿀 수 있어도 출발점은 같아야 한다</h2><p>고장 난 지갑 장치를 새것으로 바꾸는 상황을 떠올려 보자. 새 장치는 이전 거래를 본 적이 없어도, 순서대로 적힌 단어 백업과 호환되는 소프트웨어를 통해 같은 자산에 접근하는 키를 재생성할 수 있다. 종이에서 코인을 꺼내 오는 것은 아니다. 자산은 네트워크에 남아 있고, 백업은 그 자산을 제어할 수단을 되살린다. 특정인의 분실 사건이 아니라 원리를 설명하기 위한 가상 상황이다.</p><p>이 가능성에는 서로 다른 두 설계가 포개져 있다. 2012년 2월 11일 날짜의 피터르 바위어(Pieter Wuille)의 BIP32는 하나의 시드에서 키 쌍의 계층을 파생하는 구조를 설명한다. 문서가 출발점으로 삼은 문제는 독립적인 난수 키를 만들 때 반복해서 백업해야 한다는 점이었다. 같은 출발점에서 키의 나무를 다시 만들 수 있다면, 새 키가 생길 때마다 하나씩 보존할 필요가 줄어든다.</p><h2>단어보다 난수가 먼저다</h2><p>2013년 9월 10일 날짜의 BIP39에는 마렉 팔라티누스, 파볼 루스나크, 애런 보이신, 숀 보우가 저자로 올라 있다. 이 제안은 그 출발점을 사람이 다루는 문제에 집중했다. 이진수나 16진수 문자열보다 단어를 옮겨 적는 편이 수월하기 때문이다. 그러나 시작 재료는 분명 컴퓨터가 생성한 난수다. 좋아하는 명언을 고르거나 문장을 직접 만드는 것은 이 문서가 의도한 방식이 아니다.</p><p>12단어를 만들 때는 128비트 난수에 4비트 체크섬을 붙인다. 합계 132비트를 11비트씩 나누면 열두 묶음이 되고, 각 묶음은 2,048개 단어 목록에서 하나를 가리킨다. 24단어는 256비트 난수와 8비트 체크섬을 담는다. 표준에는 15·18·21단어도 있다. 단어 순서 자체가 정보이므로, 전체적인 뜻만 비슷하게 기억하면 되는 문장이 아니다.</p><p>체크섬은 소프트웨어가 일부 필사 오류를 거르는 데 도움을 준다. 하지만 모든 오류를 잡거나 빠진 정보를 대신 복구하지는 못한다. 단어를 다른 언어로 번역해서 보관해도 안 된다. BIP39는 니모닉의 글자 자체를 시드 계산에 사용한다. 사람에게 같은 뜻인 번역이라도 계산의 입력은 달라진다.</p><h2>두 번째 비밀이 목적지를 바꾼다</h2><p>니모닉 자체가 최종 시드는 아니다. BIP39는 단어와 선택적인 추가 암호문구(passphrase)를 정해진 파생 함수에 넣어 512비트 시드를 만든다. 암호문구를 쓰지 않으면 빈 문자열이 입력된다. 이후 BIP32 같은 방식이 시드에서 키를 파생한다. 이 단계를 나누어 보면 단어 백업이 송금 주소 하나도, 모든 개인키를 그대로 적은 목록도 아니라는 점이 드러난다.</p><p>추가 암호문구는 특히 혼동하기 쉽다. 장치 잠금만 푸는 PIN이 아니라 지갑을 만드는 계산의 입력이다. 다른 암호문구를 넣어도 다른 유효한 시드가 만들어진다. Trezor 문서는 이 때문에 오타가 ‘암호가 틀렸다’는 메시지 대신 보통 잔액이 없는 다른 지갑으로 이어질 수 있다고 설명한다. 원래 지갑을 복원하려면 정확한 단어 백업과 함께 당시 사용한 암호문구도 필요하다.</p><h2>고장 난 상자 밖에 남은 것</h2><p>같은 키를 다시 찾으려면 파생 규칙이 호환되고 키의 나무에서 찾는 위치도 맞아야 한다. BIP32는 서로 다른 지갑 구조를 허용한다. 따라서 단어를 읽을 수 있다는 것만으로 모든 앱에서 모든 계정을 찾는다고 보장할 수는 없다. 단어 백업이 모두 BIP39인 것도 아니다. Trezor는 SLIP39를 복원 규칙이 다른 별도 형식으로 설명한다.</p><p>BIP39가 남긴 아이디어는 교체할 수 있는 장치와 재현할 수 있는 암호학적 출발점을 분리한 데 있다. 그래서 백업은 강력하며, 단순한 메모로 취급할 수 없다. Trezor가 이를 해당 지갑에 접근할 수 있는 비밀 정보로 다루는 이유다. 작은 종이는 원래 담겨 온 상자보다 오래 살아남을 수 있다. 그 힘은 정보를 정확히 보존하고, 누가 읽을 수 있는지도 통제할 때 유지된다.</p><h2>출처</h2><ul><li><a href="https://bips.dev/39/">BIP39: 저자·단어 인코딩·시드 파생 규칙</a></li><li><a href="https://bips.dev/32/">BIP32: 계층 키와 지갑 구조</a></li><li><a href="https://trezor.io/guides/backups-recovery/advanced-wallets/what-is-a-passphrase">추가 암호문구가 지갑에 미치는 영향</a></li><li><a href="https://trezor.io/guides/backups-recovery/general-standards/how-to-use-a-wallet-backup">단어 백업으로 복원하는 것과 비밀 유지</a></li><li><a href="https://trezor.io/learn/security-privacy/personal-security-standards/understanding-trezor-wallet-backups-12-20-or-24-words">서로 다른 백업 형식 BIP39와 SLIP39</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>오스트리아 크립토 우표 — 편지는 종이로, 수집은 화면으로</title>
    <link>https://coinyq.com/ko/stories/austria-crypto-stamp-paper-digital</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/austria-crypto-stamp-paper-digital</guid>
    <pubDate>Wed, 23 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[2019년 오스트리아 우정은 실제로 쓸 수 있는 우표와 디지털 수집품의 접근 정보를 한 블록에 담았다. 두 수집 세계가 만났지만, 토큰을 옮기는 것과 편지를 배달하는 것은 여전히 다른 일이었다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/austria-crypto-stamp-paper-digital.webp" alt="오스트리아 크립토 우표 — 편지는 종이로, 수집은 화면으로" /></p><p>2019년 오스트리아 우정은 실제로 쓸 수 있는 우표와 디지털 수집품의 접근 정보를 한 블록에 담았다. 두 수집 세계가 만났지만, 토큰을 옮기는 것과 편지를 배달하는 것은 여전히 다른 일이었다.</p><h2>한 블록에 담긴 두 가지 쓰임</h2><p>2019년 6월 11일, 오스트리아 우정은 두 가지 방식으로 사용할 수 있는 우표를 내놓았다. 첫 Crypto stamp는 카드 모양의 블록이었다. 왼쪽은 떼어서 우편 발송에 쓰는 우표였고, 오른쪽에는 디지털 지갑에 접근하는 정보가 가려져 있었다. 액면은 6.90유로, 발행량은 15만 부였다. 이는 우편요금 가치와 발행 규모를 나타내는 숫자이지, 되팔 때 받을 가격의 약속이 아니었다.</p><p>유니콘 도안은 율리아 오버뮐러(Julia Obermüller)가 디자인했다. 베를린 커뮤니케이션 박물관의 도록은 실물을 오프셋·실크스크린 인쇄를 결합한 플라스틱으로 기록하며, 디지털 쌍은 이더리움에 있다고 설명한다. 봉투나 앨범에 넣을 수 있는 제작물 한쪽과, 탁자 너머로 우표를 건네지 않아도 지갑 소유자가 바뀔 수 있는 자산 다른 쪽이 만난 셈이다.</p><h2>화면 속 색깔도 수집의 대상이 됐다</h2><p>박물관은 디지털 판본에 검정·초록·파랑·노랑·빨강의 다섯 색이 있다고 설명한다. 손에 쥔 실물 외에 화면에서도 구분하고 모을 요소가 생겼다. 투자 수익 이야기를 꺼내지 않아도 이 상품의 매력을 이해할 수 있는 대목이다. 우편에 사용할 수 있는 액면가와 수집가가 지불하려는 금액은 서로 다른 척도다.</p><p>출시 발표문은 디지털 우표를 제어하는 수단으로 긁어내는 보호층 아래의 지갑 접근 정보와 비밀 단어 목록을 설명했다. 지갑 사이에서 옮긴 기록은 블록체인에 남는다고도 밝혔다. 이 구조에서 중요한 구분이 나온다. 실물을 가지고 있는지와 디지털 수집품을 제어하는지는 따로 확인할 항목이다. 이는 두 부분으로 나눈 설계에 대한 해석이며, 이후의 모든 거래에서 실물과 디지털이 분리됐다는 주장은 아니다.</p><h2>블록체인이 봉투를 나른 것은 아니다</h2><p>만국우편연합(UPU)의 2022년 연구는 유용한 경계를 그었다. 크립토 우표를 다룬 대목에서 오스트리아의 실물 우표로 소포를 보낼 수 있지만, 소포 이동을 추적하는 용도는 명시돼 있지 않다고 설명했다. 따라서 디지털 수집품이 지갑을 옮겼다는 기록을 편지가 분류센터나 수취인에게 도착했다는 증거로 읽어서는 안 된다. 연구는 더 넓은 우편 활용 가능성을 탐색했지만, 그 가능성을 모두 2019년 우표의 성과로 인정한 것은 아니었다.</p><p>그래서 이 이야기는 ‘우편이 블록체인으로 옮겨갔다’는 구호보다 작고 구체적이다. 기존 수집 습관에 디지털 쌍이 더해졌고, 익숙한 우편 용도도 남았다. 이 글의 범위는 2019년 첫 설계이며 이후의 모든 Crypto stamp 판본이 아니다. 흥미로운 질문은 그대로다. 누군가 우표를 소유한다고 말할 때, 실물과 지갑 속 자산 중 무엇을 가리킬까? 아니면 둘 다일까? 답은 실제로 어느 쪽이 손을 바꿨는지에 달려 있다.</p><h2>출처</h2><ul><li><a href="https://www.ots.at/presseaussendung/OTS_20190611_OTS0146/crypto-stamp-oesterreichische-post-praesentiert-die-erste-blockchain-briefmarke-der-welt">오스트리아 우정의 2019년 6월 11일 출시 발표</a></li><li><a href="https://www.mfk-berlin.de/wp-content/uploads/Booklet_Kuriose-Kommunikation-1.pdf">박물관 도록 항목 21: 실물 재질과 디지털 색상</a></li><li><a href="https://www.upu.int/UPU/media/upu/publications/blockchainsForAsustainablePostalFutureEn.pdf">UPU 2022년 연구 인쇄 26쪽: 수집과 배송 추적의 구분</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>ERC-1155 — 게임 가방을 한 번에 옮기는 규칙</title>
    <link>https://coinyq.com/ko/stories/erc-1155-game-inventory-batch-transfer</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/erc-1155-game-inventory-batch-transfer</guid>
    <pubDate>Tue, 22 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[검 한 자루와 물약 여러 병은 같은 방식으로 세는 자산이 아니다. ERC-1155는 모든 아이템을 고유한 NFT로 만들지 않고도, 서로 다른 종류와 수량을 한 계약에서 다루고 함께 보낼 수 있게 했다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/erc-1155-game-inventory-batch-transfer.webp" alt="ERC-1155 — 게임 가방을 한 번에 옮기는 규칙" /></p><p>검 한 자루와 물약 여러 병은 같은 방식으로 세는 자산이 아니다. ERC-1155는 모든 아이템을 고유한 NFT로 만들지 않고도, 서로 다른 종류와 수량을 한 계약에서 다루고 함께 보낼 수 있게 했다.</p><h2>가방에는 한 종류만 들어 있지 않았다</h2><p>특별한 검 한 자루와 똑같은 물약 세 병을 가방에 넣어 다른 플레이어에게 건넨다고 생각해 보자. 검은 개별 물건으로서 중요하고, 물약은 몇 병인지가 중요하다. 특정 게임에서 실제로 있었던 거래가 아니라 설명을 위한 예다. 이 가방은 ERC-1155를 이해하는 출발점이기도 하다. 보유 아이템 전체를 하나의 화폐나 고유 물건들의 컬렉션으로만 취급하지 않고, 성격이 다른 자산을 함께 담도록 설계한 토큰 인터페이스다.</p><p>제안이 만들어진 날짜는 2018년 6월 17일이다. 1년 뒤 Enjin의 비테크 라돔스키는 표준이 Final 상태에 도달했다고 발표했다. 그는 Enjin 내부에서 2017년부터 진행한 작업과 이후 커뮤니티의 표준화 과정을 설명했다. 명세에는 저자 여섯 명이 올라 있다. 게임 아이템의 필요에서 출발한 구조가 한 게임만의 형식을 넘어, 지갑과 애플리케이션이 함께 구현할 수 있는 인터페이스가 된 것이다.</p><h2>ID는 종류를, 잔액은 개수를 말한다</h2><p>ERC-1155 계약은 계정과 토큰 ID의 조합마다 보유 수량을 기록한다. 앞의 가상 가방이라면 한 ID는 서로 바꿔도 같은 물약 여러 병을 나타내고, 다른 ID는 구현상 총발행량을 하나로 제한한 검을 나타낼 수 있다. ID를 붙였다고 저절로 희귀해지는 것은 아니다. 같은 것을 더 발행할 수 있는지는 여전히 발행 규칙이 정한다.</p><p>그렇다고 ERC-721이 NFT 하나마다 새 계약을 요구했다는 뜻은 아니다. ERC-721 컬렉션도 이미 한 계약에 여러 고유 토큰을 담을 수 있었다. 차이는 ERC-1155에서 ID가 수량을 가진 종류를 가리킬 수 있다는 데 있다. 서로 대체 가능한 자산과 고유한 자산이 같은 장부 구조를 쓴다. 질문이 ‘어느 고유 토큰인가’에서 ‘어떤 종류를 몇 개 가지고 있는가’로 넓어진다.</p><h2>가방째 보내는 일괄 전송</h2><p>표준의 safeBatchTransferFrom은 ID 목록과 그에 대응하는 수량 목록을 받는다. 한 발신자가 검과 물약 세 병을 한 번의 호출로 같은 수신자에게 옮길 수 있다. 종류마다 별도 거래를 만드는 데 드는 부담을 줄일 수 있는 구조다. 이것만으로 쌍방 교환이 되는 것은 아니다. 반대 방향의 대금 지급이나 자산 교환에는 별도의 애플리케이션 로직이 필요하다.</p><p>받는 쪽이 계약이면 그 계약도 절차에 참여한다. 표준의 일반적인 안전 전송 규칙에서는 수신 계약이 정해진 수락 값을 반환해야 하며, 거절하면 거래가 되돌려진다. 호환되지 않는 계약으로 보내는 실수를 걸러내는 확인이다. 하지만 받은 아이템을 나중에 다시 내보낼 수 있다는 보장은 아니다. OpenZeppelin 구현 가이드도 개발자에게 출금에 해당하는 전송 기능을 따로 마련하라고 명시한다.</p><h2>소유 기록만으로 게임이 완성되지는 않는다</h2><p>ERC-1155가 표준화하는 것은 보유 수량·전송·이벤트 기록이지 검의 전투 동작이 아니다. 메타데이터는 이름·그림·속성을 담은 별도 JSON 문서를 가리킬 수 있다. 명세는 이런 분리를 허용하며, 모든 그림이나 게임 규칙을 영구히 온체인에 저장하라고 요구하지 않는다. 다른 게임에서 그 아이템을 인정할지, 무엇에 쓸 수 있게 할지도 해당 게임이 정해야 한다.</p><p>권한에도 중요한 경계가 있다. 표준의 setApprovalForAll은 물약 하나만이 아니라 해당 계약에서 보유한 토큰들을 운영자가 다룰 수 있게 승인한다. 편리함만큼이나 승인 범위를 알아보기 쉬운 화면이 필요하다. ERC-1155가 남긴 것은 여러 종류가 섞인 가방을 위한 공통 문법이다. 게임의 작동 방식, 그림, 다른 주체에게 통제권을 맡기는 선택에는 여전히 별도의 규칙이 필요하다.</p><h2>출처</h2><ul><li><a href="https://eips.ethereum.org/EIPS/eip-1155">ERC-1155 명세: 수량·일괄 전송·수신 계약·메타데이터</a></li><li><a href="https://enjin.io/blog/erc-1155-token-standard-ethereum/">비테크 라돔스키의 2019년 최종 표준 확정 발표</a></li><li><a href="https://docs.openzeppelin.com/contracts/5.x/erc1155">OpenZeppelin: 아이템과 수신 계약 구현 설명</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>UNICEF — 기부받은 코인을 그대로 지급하다</title>
    <link>https://coinyq.com/ko/stories/unicef-cryptofund-donations-stay-crypto</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/unicef-cryptofund-donations-stay-crypto</guid>
    <pubDate>Tue, 22 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[2019년 UNICEF는 기부받은 암호화폐를 보관했다가 같은 자산으로 지원금을 지급하는 펀드를 내놓았다. 자금이 이동하는 경로는 달라졌지만, 유용한 기술을 만들고 성과를 확인하는 일은 여전히 사람의 몫이었다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/unicef-cryptofund-donations-stay-crypto.webp" alt="UNICEF — 기부받은 코인을 그대로 지급하다" /></p><p>2019년 UNICEF는 기부받은 암호화폐를 보관했다가 같은 자산으로 지원금을 지급하는 펀드를 내놓았다. 자금이 이동하는 경로는 달라졌지만, 유용한 기술을 만들고 성과를 확인하는 일은 여전히 사람의 몫이었다.</p><h2>중요한 단어는 보관이었다</h2><p>자선단체는 암호화폐를 기부받은 뒤 환전해서 쓸 수 있다. UNICEF가 2019년 10월 발표한 경로는 달랐다. 새 CryptoFund는 기부받은 암호화폐를 그대로 보관하고, 같은 암호화폐로 지원금을 지급하도록 설계됐다. 출범 당시 명시한 자산은 비트코인과 이더였다. 기부 페이지에 결제 버튼 하나를 더 붙이는 데서 끝나지 않는 기관의 실험이었다.</p><p>출범 보도자료는 이더리움 재단이 UNICEF 프랑스 국가위원회를 통해 첫 기부를 하고, Innovation Fund의 세 지원 대상과 GIGA가 조정하는 학교 인터넷 연결 사업을 돕게 된다고 설명했다. 기술 사업을 위한 지원금이었다. 아이들에게 암호화폐를 나눠 주거나 UNICEF 전체의 자금 체계를 바꾼다는 발표는 아니었다.</p><h2>자산이 개발팀에 도착했다</h2><p>2020년 6월 19일 UNICEF는 7개국 8개 기업을 대상으로 한 지원을 발표했다. 기업마다 125 ETH를 받아 6개월 동안 기술을 개발·시험하거나 규모를 넓히는 내용이었다. 대상 기업들은 이미 Innovation Fund의 지원을 받은 곳들이었다. 새 암호화폐 지원은 공개 소프트웨어 개발을 이어가는 수단이었으며, 코인을 사는 일반 대중을 위한 투자상품이 아니었다.</p><p>포트폴리오를 보면 그 차이가 구체적으로 드러난다. UNICEF의 6월 16일 설명에는 Afinidata의 영유아 학습 지원, StaTwig의 공급망 추적, Utopic의 독서 게임 같은 사업이 나온다. 암호화폐로 지원받은 기업이라고 제품의 모든 부분을 블록체인으로 만들 필요는 없었다. 지원금을 전달하는 자산과 실제로 개발하는 기술은 서로 다른 선택이었다.</p><h2>지급은 빨라도 성과 확인에는 시간이 든다</h2><p>6월 19일 보도자료에서 UNICEF 자문역 크리스 파비언은 8개 기업으로의 송금에 20분 미만이 걸렸고 비용은 20달러 미만이었다고 설명했다. 해당 지원 건에 대해 기관이 보고한 결과이지, 언제나 같은 가격과 속도를 보장한다는 뜻은 아니다. 운영 경험으로는 의미가 있지만, 돈이 빨리 도착했다는 사실로 시제품이 현장에서 작동하기까지 걸릴 시간을 알 수는 없다.</p><p>전체 포트폴리오의 지원 과정에는 여전히 사람과 단계별 목표가 있었다. UNICEF의 2021년 설명은 기업별로 합의한 1년 작업 계획, 기술·오픈소스 멘토링, 진척에 따라 나눠 지급하는 법정화폐 자금을 소개한다. 이 Innovation Fund의 절차를 모든 암호화폐 지원금이 동일한 일정으로 자동 지급됐다는 주장과 혼동해서는 안 된다. 송금 성공이 프로그램의 한 부분에 불과한 이유를 보여 주는 대목이다.</p><p>UNICEF는 2021년 6월 공개 송금 기록을 회계의 가시성을 높이는 추가 층으로 설명했다. 블록체인이 사업 성과를 증명한다는 말보다 범위가 좁고 쓸모가 분명한 주장이다. 자산이 움직인 기록은 기부자가 자금을 따라가는 데 도움이 된다. 학습 도구가 효과가 있는지 확인하려면 도구와 사용자에 관한 근거가 필요하다. 초기 CryptoFund는 자금의 경로를 더 직접 관찰할 수 있게 하는 실험이었다. 최종 성과까지 거래 한 건으로 인증해 주는 장치는 아니었다.</p><h2>출처</h2><ul><li><a href="https://www.unicef.org/press-releases/unicef-launches-cryptocurrency-fund">UNICEF의 2019년 출범 발표와 초기 자산 지급 구조</a></li><li><a href="https://www.unicef.org/press-releases/unicef-cryptocurrency-fund-announces-its-largest-investment-startups-developing-and">2020년 6월 19일 UNICEF의 기업 지원 발표</a></li><li><a href="https://www.unicef.org/innovation/CryptoFundInvestments">2020년 6월 16일: 8개 지원 사업의 기술 구성</a></li><li><a href="https://www.unicef.org/innovation/stories/unicef-innovation-fund-portfolio-experience">2021년 포트폴리오 설명: 작업 계획·멘토링·자금 지원</a></li><li><a href="https://www.unicef.org/innovation/InnovationFund/blockchain-financial-inclusion-cohort">2021년 6월: 공개 송금 기록과 회계의 가시성</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>Nouns — 누구나 쓰는 그림, 소유자가 행사하는 한 표</title>
    <link>https://coinyq.com/ko/stories/nouns-public-art-auction-voting</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/nouns-public-art-auction-voting</guid>
    <pubDate>Mon, 21 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[Nouns는 NFT 경매를 공동 금고와 연결하면서 그림은 누구나 쓰도록 열어 두었다. 초기 설계에서 그림을 재사용할 권리와 돈의 사용처를 결정할 권한은 서로 다른 길로 움직였다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/nouns-public-art-auction-voting.webp" alt="Nouns — 누구나 쓰는 그림, 소유자가 행사하는 한 표" /></p><p>Nouns는 NFT 경매를 공동 금고와 연결하면서 그림은 누구나 쓰도록 열어 두었다. 초기 설계에서 그림을 재사용할 권리와 돈의 사용처를 결정할 권한은 서로 다른 길로 움직였다.</p><h2>안경 하나, 서로 다른 참여 방식</h2><p>Nouns의 네모난 안경을 그림에 넣기 위해 해당 NFT를 살 필요는 없다. 한편 NFT를 사면 공동 금고의 의사결정에 참여할 수 있다. 두 문은 서로 다르게 열려 있다. 프로젝트의 공식 설명은 그림을 퍼블릭 도메인으로 공개하는 동시에 Noun 하나에 거버넌스 한 표를 부여한다. 이미지는 자유롭게 퍼뜨리되 특정한 결정 권한은 토큰에 연결하는 것이 이 실험의 특징이었다.</p><p>Nouns는 2021년 NFT 열풍 속에 등장했다. 8월 10일에 공개된 Remilia의 글은 8월 8일 첫 경매 판매를 기록하며, 한꺼번에 많은 캐릭터를 내놓는 대신 하나씩 등장하는 컬렉션을 설명했다. 낙찰 대금은 공동 금고로 들어갔다. 다음 프로필 사진을 누가 쓸 것인가에 더해, 토큰을 가진 사람들이 함께 무엇을 만들 것인가라는 질문이 붙은 셈이다.</p><h2>하루의 끝에는 거래가 필요했다</h2><p>초기 설계는 새 Noun을 24시간 경매에 올렸다. 입찰 기간이 끝난 뒤 정산하면 토큰은 낙찰자에게, 경매 대금은 금고로 옮겨지고 다음 경매가 시작될 수 있었다. Nouns Center의 안내는 쉽게 놓치는 단계를 분명히 한다. 화면의 시간이 다 지났다고 정산까지 저절로 끝나는 것은 아니었다. 누군가 거래를 보내야 했다. 계약의 조건을 충족하면 누구나 그 정산을 실행할 수 있었다.</p><p>그 주기도 고정된 벽시계와 같지는 않았다. 초기 경매 코드는 마감 직전의 설정된 시간 구간에 새 입찰이 들어오면 종료 시점을 늘렸다. 소유자는 새 경매를 일시 정지할 수 있었고, 입찰이 전혀 없는 Noun은 정산 때 소각됐다. 매일의 리듬은 조건을 갖춘 장치였지, 영원히 정확히 같은 시각에 구매자와 새 판매가 나타난다는 약속은 아니었다.</p><p>‘하루 한 개’라는 설명에는 또 다른 예외가 있었다. 토큰 계약은 ID 0부터 1820까지 열 개마다 하나를 창립자 조직에 배정했다. 최대 183개의 창립자 보상이었다. 낙찰금에서 일부를 떼는 방식이 아니라 토큰을 배정하는 방식이다. 경매 대금 전액이 금고로 간다는 설명을 읽을 때 중요한 차이다. 그것이 창립자에게 아무 배정도 없었다는 뜻은 아니었다.</p><h2>그림은 퍼지고, 표에는 주인이 남는다</h2><p>그림을 보관하는 방식도 눈에 띄었다. 계약 문서는 압축해 저장한 부분들을 조합해 SVG 이미지를 만들고 토큰 데이터에 포함하는 과정을 설명한다. 이는 그림이 어디에서 만들어지는가의 문제다. 퍼블릭 도메인 공개는 다른 사람이 그림을 어떻게 재사용할 수 있는가의 문제다. 어느 쪽도 이미지를 저장하거나 다시 그렸다는 이유만으로 새 투표권을 만들지는 않는다.</p><p>공동 금고는 소유자에게 함께 결정할 일을 남겼다. 구매자가 자신이 낸 경매 대금의 사용처를 혼자 정하는 대신, 보유자들은 제안과 거버넌스를 통해 자금의 방향을 결정했다. 기준은 한 사람 한 표가 아니라 Noun 하나당 한 표였다. 여러 토큰을 보유하면 여러 표를 행사할 수 있다는 뜻이다. 그림이 퍼지는 범위와 결정 권한의 분포는 서로 다른 규칙을 따랐다. 초기 거버넌스에는 창립자의 거부권도 있었으므로, 토큰으로 투표한다는 것이 안전장치나 별도 권한의 부재를 뜻하지는 않았다.</p><p>Nouns의 초기 설계에서 흥미로운 긴장은 여기에 있다. 포스터를 만드는 사람은 투표자가 되지 않고도 시각 문화에 참여할 수 있다. 경매 낙찰자는 토큰을 얻고, 다른 보유자들과 함께 정할 일의 재원을 보탠다. 자유롭게 쓰는 그림이 사람을 모을 수는 있지만, 그 그림만으로 공동 금고의 사용처까지 정할 수는 없다.</p><h2>출처</h2><ul><li><a href="https://blog.remilia.org/nouns-wtf/">첫 경매와 초기 설계를 기록한 동시대 글</a></li><li><a href="https://nouns.center/intro">Nouns Center의 경매·정산·투표 안내</a></li><li><a href="https://raw.githubusercontent.com/nounsDAO/nouns-monorepo/master/packages/nouns-contracts/README.md">공식 계약 문서: 이미지 생성·경매·금고</a></li><li><a href="https://raw.githubusercontent.com/nounsDAO/nouns-monorepo/master/packages/nouns-webapp/src/components/Documentation/index.tsx">공식 웹사이트 설명의 소스 코드</a></li><li><a href="https://raw.githubusercontent.com/nounsDAO/nouns-monorepo/master/packages/nouns-contracts/contracts/NounsToken.sol">NounsToken의 창립자 보상 발행 규칙</a></li><li><a href="https://raw.githubusercontent.com/nounsDAO/nouns-monorepo/master/packages/nouns-contracts/contracts/NounsAuctionHouse.sol">초기 경매 계약의 정산·연장·일시 정지</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>원자적 교환 — 먼저 받는 사람이 공개해야 할 비밀</title>
    <link>https://coinyq.com/ko/stories/decred-litecoin-atomic-swap-secret</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/decred-litecoin-atomic-swap-secret</guid>
    <pubDate>Mon, 21 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[2017년 Decred와 Litecoin의 교환은 누가 먼저 보내야 하는가라는 문제를 다뤘다. 두 계약과 하나의 비밀값, 서로 다른 환불 기한이 거래소에 두 자산을 맡기지 않고 교환을 연결했다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/decred-litecoin-atomic-swap-secret.webp" alt="원자적 교환 — 먼저 받는 사람이 공개해야 할 비밀" /></p><p>2017년 Decred와 Litecoin의 교환은 누가 먼저 보내야 하는가라는 문제를 다뤘다. 두 계약과 하나의 비밀값, 서로 다른 환불 기한이 거래소에 두 자산을 맡기지 않고 교환을 연결했다.</p><h2>누가 먼저 보내야 할까</h2><p>두 사람이 가격에 합의해도 문제는 남는다. 한쪽이 코인을 먼저 보내면, 상대가 자기 몫을 보내도록 무엇이 보장할까? Decred가 2017년 9월 20일 공개한 글은 전날 Decred와 Litecoin 사이에 원자적 교환이 이뤄졌다고 기록했다. 함께 공개한 도구는 제3의 보관자에게 돈을 넘기지 않고 두 지급을 연결하는 방법을 보여 줬다. 라이트닝 결제 채널이 아니라 각 체인에 거래를 남기는 온체인 교환이었다.</p><p>두 체인이 하나의 장부로 합쳐진 것은 아니다. 각각 서명 확인, 호환되는 해시 검사, 시간 잠금 조건을 지원해야 했다. 이 조건은 맡긴 자금에 두 갈래를 만든다. 상대가 수령 조건을 충족해 가져가거나, 기한이 지난 뒤에도 쓰이지 않은 자금을 예치자가 회수한다. 스크립트에서 같은 해시 함수를 쓸 수 있어야 했으며, 채굴 알고리즘까지 같아야 하는 것은 아니었다.</p><h2>돈을 받으려면 비밀을 드러내야 한다</h2><p>저장소의 예제는 Bitcoin과 Decred로 순서를 설명한다. 시작한 사람이 비밀값을 만들고 비트코인을 계약에 잠근 뒤, 비밀 자체가 아닌 그 해시를 전달한다. 상대는 다른 체인에서 같은 해시 조건으로 디크레드를 잠근다. 수령자의 서명도 필요하다. 비밀값을 알게 됐다는 이유만으로 관계없는 구경꾼이 자금을 가져갈 수 있는 구조는 아니다.</p><p>시작한 사람이 디크레드를 받는 거래에 비밀값을 공개한다. 상대는 그 거래에서 값을 추출해 비트코인을 받을 수 있다. 문서의 도구는 먼저 만든 계약에 보통 48시간, 두 번째 계약에 보통 24시간의 환불 대기 시간을 둔다. 그 차이가 공개된 비밀값으로 상대가 행동할 시간을 남긴다. 이 숫자는 해당 도구의 예시 설정이지 모든 원자적 교환에 정해진 보편적 시간은 아니다.</p><h2>원자적이라는 말은 즉시 끝난다는 뜻이 아니다</h2><p>실제로는 서로 다른 거래와 블록, 대기 시간이 존재한다. 참여자는 계약을 확인하고 시간이 남아 있을 때 수령 거래를 지켜봐야 한다. 수령 전에 교환이 중단되면 해당 기한 이후 아직 쓰이지 않은 자금을 환불받는 경로가 열린다. 조건에 따른 예치금 회수이지, 이미 발생한 모든 거래를 자동으로 되돌리는 기능은 아니다. README는 2018년 3월 1일의 보강도 기록한다. 체인별 데이터 크기 차이를 악용한 교환을 막으려고 비밀값 크기를 제한했다. 깔끔한 프로토콜 아이디어에도 세심한 구현이 필요했다.</p><p>2017년 발표는 다른 한계도 분명히 밝혔다. 문자 기반 도구로 사용자끼리 정보를 전달해야 했고 주문장은 제공하지 않았다. 거래마다 체인 수수료를 내고 블록을 기다려야 했다. 같은 해시를 쓰므로 장부를 관찰하는 사람이 두 체인의 거래를 연결할 수도 있었다. 거래소의 보관 역할을 없애는 것과 즉시·무료·비공개 거래를 만드는 것은 별개였다.</p><h2>거래소가 하던 일은 하나가 아니었다</h2><p>Decred는 2018년 6월 DEX 제안에서 남은 일로 돌아왔다. 이용자는 가격을 주고받을 곳, 주문을 제출하고 짝을 찾는 기능, 지킬 수 없는 주문을 막는 장치가 필요했다. 원자적 교환이 맞춰진 두 거래의 결제 방법을 다룬다면, 그 짝을 만드는 일은 시스템의 다른 부분이었다. 이 제안은 그런 서비스를 만들기 위한 설계였지, 2017년 명령줄 도구가 이미 모두 제공했다는 기록은 아니다.</p><p>초기 교환의 성취는 이 작은 범위에서 더 또렷해진다. 한 사람이 받기 위해 한 행동이 상대가 받을 때 필요한 정보를 드러낸다. 서로 다른 기한은 두 번째 행동이 이뤄질 여유를 준다. 두 코인은 각자의 체인에 남지만, 자금을 쓸 수 있는 조건이 교환을 이어 준다. 보관자를 믿는 자리를 절차가 대신했고, 그 절차의 확인과 시간은 여전히 중요했다.</p><h2>출처</h2><ul><li><a href="https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/">2017년 9월 공식 발표: 온체인 교환과 한계</a></li><li><a href="https://github.com/decred/atomicswap/blob/master/README.md">원자적 교환 README: 순서·기한·계약 확인·2018년 보강</a></li><li><a href="https://docs.decred.org/advanced/atomic-swap/">Decred 문서: 스크립트 조건과 제약</a></li><li><a href="https://blog.decred.org/2018/06/05/A-New-Kind-of-DEX/">2018년 6월 DEX 설계: 추가로 필요한 시장 기능</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>SBB — 발권기에 비트코인 메뉴가 생긴 날</title>
    <link>https://coinyq.com/ko/stories/sbb-ticket-machines-buying-bitcoin</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/sbb-ticket-machines-buying-bitcoin</guid>
    <pubDate>Sun, 20 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[2016년 11월, 스위스 철도 발권기에 비트코인 구매 메뉴가 들어왔다. 일상적인 기기와 유통망을 활용한 실험이었다. 코인을 사는 일과 기차표 값을 내는 일은 여전히 별개였다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/sbb-ticket-machines-buying-bitcoin.webp" alt="SBB — 발권기에 비트코인 메뉴가 생긴 날" /></p><p>2016년 11월, 스위스 철도 발권기에 비트코인 구매 메뉴가 들어왔다. 일상적인 기기와 유통망을 활용한 실험이었다. 코인을 사는 일과 기차표 값을 내는 일은 여전히 별개였다.</p><h2>발권기 메뉴에 더해진 목적지</h2><p>2016년 10월 28일, 스위스 철도회사 SBB는 발권기와는 조금 낯선 소식을 발표했다. 곧 그 기계에서 비트코인을 살 수 있게 된다는 것이었다. 시작일은 11월 11일로 잡혔다. 이용자는 프랑을 내고 자신의 비트코인 지갑으로 코인을 받을 수 있었다. 다만 새 서비스로 비트코인을 써서 기차표 값을 낼 수는 없었다. 성격이 다른 두 거래가 같은 기계 안에 들어온 셈이었다.</p><p>SBB는 수요를 알아보기 위한 2년짜리 시험이라고 설명했다. 무대는 이미 운영하던 1,000대가 넘는 발권기였다. 승차권과 다른 서비스를 사는 익숙한 장소였고, 회사는 이 유통망의 24시간 접근성을 강조했다. 실험의 규모를 만든 것은 기존 망의 재활용이었다. 암호화폐 전용 기기를 새로 곳곳에 설치할 필요가 없었다.</p><h2>실제로 기계 앞에서 한 일</h2><p>Bitcoin.com이 12월에 공개한 직접 사용 기록은 개시 첫날의 순서를 보여 준다. 기자는 발권기의 기타 서비스와 선불 메뉴를 거쳐 비트코인 항목으로 들어갔다. 지갑의 QR 코드를 스캔한 뒤 금액과 구매 조건을 확인하고, 문자로 받은 보안 코드를 입력한 다음 스위스 프랑으로 결제했다. 이후 지갑에 비트코인이 들어왔다고 기록했다. 이는 2016년 서비스를 관찰한 설명이지, 이후 버전의 절차나 송금 소요 시간을 보장하는 말은 아니다.</p><p>기계만큼 중요한 것은 환전을 맡은 상대였다. SBB는 판매 창구를 제공하고, 고객은 추크에 있는 SweePay와 직접 환전했다. 당시 SRF는 구매 가능 금액을 20~500스위스 프랑으로 전하면서 지갑과 휴대전화 인증이 필요하다고 설명했다. 12월 인터뷰에서 SweePay 대표 로돌프 텍시에는 스위스 휴대전화 번호도 요건으로 꼽았다. 현금을 받는 기계라는 이유로 익명으로 아무 절차 없이 거래할 수 있었던 것은 아니다.</p><h2>철도가 보탠 것은 무엇이었나</h2><p>텍시에는 SweePay가 이미 선불 상품을 유통하고 있었으며, 휴대전화 충전 같은 서비스를 처리하던 철도 발권기를 비트코인 구매자에게 닿는 유용한 경로로 보았다고 설명했다. 그가 밝힌 목표는 비트코인을 더 쉽게 구하도록 하는 것이었다. 발권기는 그 일에 결제 화면과 실제 장소의 연결망을 보탰다. 사람들이 이 서비스를 얼마나 원할지는 시험을 통해 알아보려던 질문이었다.</p><p>비트코인이 기차역에 등장했다는 장면만 보면 놓치기 쉬운 차이가 있다. 돈을 새로 구할 수 있는 장소가 곧 그 돈을 쓸 수 있는 장소가 되지는 않는다. SBB의 출시 발표는 비트코인을 승차권 결제 수단에서 명시적으로 제외했다. 이 실험의 흥미는 경로가 조금 달라졌다는 데 있다. 익숙한 기계가 프랑과 디지털 지갑을 이어 주는 동안, 철도는 여전히 여행의 대금을 별도로 받고 있었다.</p><h2>출처</h2><ul><li><a href="https://bitcoin.fr/chemins-de-fer-federaux-suisses-adoptent-bitcoin/">bitcoin.fr에 재수록된 SBB 출시 발표</a></li><li><a href="https://www.srf.ch/news/wirtschaft/wirtschaft-sbb-steigt-in-den-bitcoin-handel-ein">시험 서비스를 다룬 당시 SRF 보도</a></li><li><a href="https://news.bitcoin.com/switzerland-densest-bitcoin-atm-network/">직접 사용 기록과 SweePay 대표 인터뷰</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>PoolTogether — 당첨금은 어디에서 오는가</title>
    <link>https://coinyq.com/ko/stories/pooltogether-interest-funded-prize-savings</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/pooltogether-interest-funded-prize-savings</guid>
    <pubDate>Sun, 20 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[2019년 출시된 PoolTogether는 예치금을 상금으로 쓰는 대신, 거기서 생긴 이자를 모아 추첨했다. 초기 설계에는 상금 연계 저축의 매력과 ‘무손실’이라는 이름의 한계가 함께 드러난다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/pooltogether-interest-funded-prize-savings.webp" alt="PoolTogether — 당첨금은 어디에서 오는가" /></p><p>2019년 출시된 PoolTogether는 예치금을 상금으로 쓰는 대신, 거기서 생긴 이자를 모아 추첨했다. 초기 설계에는 상금 연계 저축의 매력과 ‘무손실’이라는 이름의 한계가 함께 드러난다.</p><h2>낙첨 뒤에도 남는 예치금</h2><p>2019년 6월 24일, 레이턴 쿠삭은 복권과는 어울리지 않는 듯한 제안으로 PoolTogether를 소개했다. 참가했다가 당첨되지 않아도 예치금은 남는다는 것이었다. 프로젝트는 Ethereum에서 DAI를 사용했다. 출시 글은 이를 기존의 상금 연계 저축에 연결했다. 당첨을 기다리는 재미를, 쓰고 없어지는 복권값 대신 따로 모아 둔 돈에 붙이는 방식이다.</p><p>그래도 당첨금의 재원은 필요했다. PoolTogether의 답은 함께 모인 돈에서 생기는 이자였다. 참가자는 자신의 이자 몫을 직접 받는 대신, 합쳐진 당첨금을 받을 기회를 선택했다. 그래서 낙첨자의 예치금은 유지하면서 공동 수익은 다른 사람에게 줄 수 있었다. 기회비용까지 없어진 것은 아니다. 각자가 받을 수 있었던 이자가 추첨에 들어갔다.</p><h2>자금 풀에도 달력이 필요하다</h2><p>그해 8월 공개된 v2 설계는 이 참여를 반복할 수 있게 했다. 예치금은 이자를 얻도록 Compound에 공급하고, Pool 계약은 이용자별 몫을 기록했다. 돈을 디지털 상자에 가만히 넣어 둔 구조가 아니었다. 신규 입금을 받는 open 단계와 추첨 자격이 확정된 committed 단계가 각각 일주일씩 이어지며 서로 겹쳤다. 새 입금은 open 단계를 거쳐 자격을 얻고, 이미 자격을 얻은 예치금은 매번 표를 새로 사지 않아도 다음 추첨에 남을 수 있었다.</p><p>자격은 확률도 정했다. 개발자의 예시에서 추첨 대상 1,000 DAI 중 100 DAI를 보유하면 당첨 확률은 10%였다. 아직 open 단계에 있던 별도의 40 DAI는 포함하지 않았다. 사람 수가 아니라 추첨에 들어간 금액이 기준이었다. 매주 당첨금이 나온다고 새 입금이 곧바로 당첨될 수 있는 것은 아니었고, 같은 풀에 있다고 예치액이 다른 사람들의 확률까지 같아지는 것도 아니었다.</p><h2>다음 추첨을 여는 사람</h2><p>초기 시스템에는 운영자가 남아 있었다. 2020년 1월 공개 글에서 팀은 관리자만 추첨을 열고 상금을 지급할 수 있으며, 당첨자 선정에 쓰이는 비밀값도 관리자가 제공한다고 설명했다. 계약을 업그레이드하려면 창립팀 구성원 두 명의 승인이 필요했다. 이는 당시 버전에 공개된 권한이며, 이후의 모든 PoolTogether 배포에 그대로 적용되는 설명은 아니다. 장부를 Ethereum에 올렸다고 운영상의 결정까지 모두 사라진 것은 아니었다.</p><p>같은 글은 다른 배분 규칙도 설명했다. 추첨별로 이자의 일정 비율을 지정된 수혜자에게 먼저 배정하고 나머지를 당첨자에게 줄 수 있었다. 처음에는 이자의 10%를 풀로 되돌렸지만 12월에 이를 0%로 낮췄다고 밝혔다. 따라서 당첨금을 설명할 때도 당시 규칙을 봐야 한다. 재원은 이자였지만, 당첨자에게 도달하는 금액은 해당 추첨의 배분 조건에 달려 있었다.</p><h2>‘무손실’이 설명한 범위</h2><p>PoolTogether의 위험 문서는 프로토콜이나 연계 서비스에 문제가 생기면 예치금도 손실될 수 있다고 분명히 설명한다. 예치한 자산, Ethereum, 대출 서비스와 PoolTogether 자체 계약이 함께 이 구조를 이루었다. 상금 계산에서 원금을 빼 두었다고 이런 실패에 대한 보험이 생기는 것은 아니다. 추첨에서 떨어지는 일과 예치금을 돌려받지 못하는 일은 서로 다른 종류의 손실이었다.</p><p>이 실험은 기대를 거는 대상을 옮겼다. 낙첨하면 사라질 돈을 먼저 쓰게 하는 대신, 저축에서 생기는 수익을 모아 불확실한 보상으로 만들자고 제안했다. 매력은 공짜로 돈을 만들어 낸다는 데 있지 않고 그 선택에 있었다. 초기 아이디어를 이해하려면 두 몫을 함께 따라가면 된다. 참가자에게 남기도록 설계한 예치금, 그리고 다른 사람이 받을 수도 있도록 내놓은 이자다.</p><h2>출처</h2><ul><li><a href="https://medium.com/pooltogether/introducing-pooltogether-2f80c7c0bfc6">PoolTogether 출시 발표</a></li><li><a href="https://medium.com/pooltogether/inside-pooltogether-v2-0-e7d0e1b90a08">초기 v2 설계와 추첨 순서</a></li><li><a href="https://github.com/pooltogether/user-docs/blob/main/security/risks/README.md">공식 위험 설명 문서</a></li><li><a href="https://medium.com/pooltogether/pooltogether-v2-0-audit-disclosures-d968a1875ec">2020년 1월 팀의 감사 후 공개 글</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>Trezor — 마지막 확인은 작은 화면에서</title>
    <link>https://coinyq.com/ko/stories/trezor-small-screen-transaction-consent</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/trezor-small-screen-transaction-consent</guid>
    <pubDate>Sat, 19 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[Trezor는 개인키를 별도 장치에 넣었다. 눈에 더 잘 보이는 발명은 작은 화면과 물리 버튼이었다. 컴퓨터가 무엇에 서명하라고 요청하는지, 소유자가 직접 확인하는 자리다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/trezor-small-screen-transaction-consent.webp" alt="Trezor — 마지막 확인은 작은 화면에서" /></p><p>Trezor는 개인키를 별도 장치에 넣었다. 눈에 더 잘 보이는 발명은 작은 화면과 물리 버튼이었다. 컴퓨터가 무엇에 서명하라고 요청하는지, 소유자가 직접 확인하는 자리다.</p><h2>할 일을 줄인 컴퓨터</h2><p>Trezor의 초기 시제품 회고에는 이미 핵심 부품이 등장한다. 라즈베리 파이에 연결한 화면과 버튼 두 개, USB 포트다. 파볼 ‘스틱’ 루스나크와 마레크 ‘슬러시’ 팔라티누스가 만들던 것은 역할이 좁은 작은 컴퓨터였다. 지갑을 조작하는 범용 컴퓨터와 개인키를 보관하는 공간을 분리하려는 장치였다. 회사는 Model One의 공식 출시일을 2014년 7월 29일로 기록한다.</p><p>분리되는 것은 동전이 아니라 서명 권한이다. 비트코인이 플라스틱 상자 안으로 들어가는 것은 아니다. 쓸 수 있는 출력은 블록체인에 기록되고, 장치는 지출을 승인하는 데 필요한 비밀 정보를 보관한다. Trezor가 설명하는 구조에서는 거래 정보를 장치로 보내고, 장치가 서명한 거래를 연결된 컴퓨터로 돌려주어 네트워크에 전파한다. 정상적인 서명 과정에서 개인키 자체를 내보낼 필요는 없다.</p><h2>읽은 다음에 누르는 버튼</h2><p>비밀을 컴퓨터 밖에 보관하는 것만으로 그 컴퓨터에 무엇을 요청할 권한이 있는지까지 정해지지는 않는다. 변조된 앱이 다른 주소로 보내는 거래를 제안할 수도 있다. 장치가 요청을 무조건 서명한다면 키는 숨겨진 채로도 돈이 뜻하지 않은 곳으로 갈 수 있다. 화면은 승인 전에 그 행동을 살펴볼 수 있게 하는 장치다.</p><p>Trezor의 비트코인 서명 문서는 장치가 연결된 컴퓨터에 거래 데이터를 요청하고, 사용자에게 목적지·수수료·보낼 총액을 확인받는 과정을 설명한다. Model One의 자체 화면과 물리 버튼 두 개는 이를 위한 별도의 통로다. 이 일반적인 송금 흐름에서는 사람도 승인 과정의 일부다. 내용을 읽고 의도한 송금과 대조한 뒤 확인한다.</p><h2>보낼 때와 받을 때의 확인</h2><p>소프트웨어의 이력을 보면 기능의 경계도 또렷해진다. 초기 펌웨어 변경 기록은 수신 주소를 화면으로 검증하는 기능이 2014년 12월 버전 1.3.0에서 추가됐다고 적고 있다. 그 기능이 더 이른 모든 시연에도 있었다고 거꾸로 추정해서는 안 된다. 돈을 보내는 거래의 승인과 돈을 받을 주소의 확인은 같은 화면을 활용하지만 서로 다른 작업이다.</p><p>받을 때는 컴퓨터에 표시된 주소가 지갑이 생성한 주소와 같은지 대조한다. 보낼 때는 장치가 서명하려는 목적지와 금액이 자신의 의도와 맞는지 확인한다. Trezor의 화면 안내에는 한 가지 구분이 더 있다. 장치는 사용하는 주소를 보여줄 수 있지만, 누군가 건넨 주소가 정말 올바른 사람의 것인지는 알아내지 못한다. 화면이 정확하다고 요청한 사람까지 정직해지는 것은 아니다.</p><h2>장치 밖에 남는 책임</h2><p>백업에도 별도의 경계가 있다. Trezor 문서는 장치를 잃어도 백업으로 지갑 접근을 복구할 수 있다고 설명한다. 같은 이유로 필요한 백업 정보를 가진 사람은 원래 장치 없이도 지갑에 접근할 수 있다. 서명 장치를 지키는 일과 복구 정보를 지키는 일은 연결되어 있지만, 어느 한쪽이 다른 쪽을 대신하지는 않는다.</p><p>Model One의 작은 화면은 암호학적 연산을 사람이 검토할 수 있는 행동으로 바꿨다. 하드웨어와 소프트웨어에 대한 신뢰나 수신자를 판단할 필요까지 없앤 것은 아니다. 오래 남는 아이디어는 더 구체적이다. 컴퓨터가 요청을 준비하고, 별도 공간이 키를 보관하며, 소유자는 실행 직전에 내용을 확인한다. 버튼을 누르기 전에 읽을 수 있는 것이 있기에 그 버튼이 의미를 갖는다.</p><h2>출처</h2><ul><li><a href="https://trezor.io/blog/news/a-decade-of-pioneering-10-years-since-trezors-first-hardware-wallet-revolution">Trezor 10주년 제품 개발 회고</a></li><li><a href="https://trezor.io/learn/basics/what-is-a-hardware-wallet">하드웨어 지갑의 키·서명·백업</a></li><li><a href="https://docs.trezor.io/trezor-firmware/common/bitcoin-signing.html">비트코인 서명 흐름</a></li><li><a href="https://trezor.io/guides/trezor-devices/trezor-fundamentals/trezor-s-trusted-display-verify-every-address-on-your-device">신뢰할 수 있는 화면이 확인하는 것</a></li><li><a href="https://github.com/trezor/trezor-firmware/blob/main/legacy/firmware/CHANGELOG.md">초기 펌웨어 변경 기록: 2014년 12월</a></li><li><a href="https://trezor.io/learn/security-privacy/how-trezor-keeps-you-safe/trezor-hardware-built-in-security">Model One의 화면과 물리 버튼</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>슬러시 풀 — 함께 채굴해 나누는 기다림</title>
    <link>https://coinyq.com/ko/stories/slush-pool-shared-mining-variance</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/slush-pool-shared-mining-variance</guid>
    <pubDate>Fri, 18 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[2010년, 작은 컴퓨터는 몇 주를 돌려도 블록 하나를 찾지 못했다. 슬러시는 힘을 모으자고 제안했다. 공동 채굴은 보상을 기다리는 방식을 바꾸면서, 누가 실제로 일했는지 확인해야 하는 새 문제를 낳았다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/slush-pool-shared-mining-variance.webp" alt="슬러시 풀 — 함께 채굴해 나누는 기다림" /></p><p>2010년, 작은 컴퓨터는 몇 주를 돌려도 블록 하나를 찾지 못했다. 슬러시는 힘을 모으자고 제안했다. 공동 채굴은 보상을 기다리는 방식을 바꾸면서, 누가 실제로 일했는지 확인해야 하는 새 문제를 낳았다.</p><h2>CPU 세 개를 돌려도 오지 않은 블록</h2><p>2010년 11월 27일, 슬러시라는 포럼 이용자는 몇 주째 CPU 세 개로 채굴했지만 블록을 찾지 못했다고 썼다. GPU 채굴이 등장하면서 작은 컴퓨터와 강력한 장비의 격차가 더욱 눈에 띄었다. 그가 내놓은 제안은 작은 채굴자들의 힘을 모아 블록을 찾고, 얻은 보상을 나누자는 것이었다.</p><p>다른 참여자 ribuck은 제안의 전제 하나를 바로잡았다. 난이도가 같다면 컴퓨터 두 대를 묶는다고 합산 연산 능력의 기대 수익이 마법처럼 커지지는 않는다. 슬러시의 답변은 현실적인 문제를 더 선명하게 드러냈다. 첫 보상이 너무 멀어 보이면 사람들이 채굴기를 꺼버릴 수 있다는 것이다. 적더라도 더 자주 받는 보상이 참여를 이어갈 동기가 될 수 있었다.</p><h2>큰 보상 하나와 고르지 않은 기다림</h2><p>당시 비트코인의 블록 보조금은 50 BTC였다. 혼자 채굴해 유효한 블록을 찾으면 그 보조금을 받을 수 있었지만, 작은 장비로는 오랫동안 아무것도 찾지 못할 수 있었다. 풀은 여러 컴퓨터의 작업을 모으고 보상을 나눴다. 참가자는 보상을 통째로 가질 기회를 내놓는 대신, 풀이 성공할 때마다 자신의 몫을 받는 방식을 택했다.</p><p>달라지는 것은 실제 결과가 평균에서 얼마나 크게 흔들리는가를 뜻하는 분산이다. 유효한 연산 능력이 같고 수수료를 제외한다면, 풀에 들어갔다는 이유만으로 기대 보상이 늘지는 않는다. 시간에 따른 보상의 분포가 달라진다. 풀에도 오래 블록을 못 찾는 시기가 있을 수 있고 지급 시점은 운영 규칙에도 달려 있다. 협력이 매일의 수입을 보장하는 것은 아니다.</p><h2>당첨되지 않은 작업을 세는 방법</h2><p>풀은 컴퓨터가 열심히 일했다고 주장하는 것만으로 돈을 나눠줄 수 없다. 그래서 비트코인 블록에 필요한 기준보다 쉬운 목표를 충족한 결과를 요구한다. 이를 셰어(share)라고 부른다. 풀은 셰어를 적은 비용으로 검증할 수 있고, 제출 빈도와 난이도를 함께 보면 기여한 작업량을 통계적으로 추정할 수 있다. 대부분의 셰어는 비트코인 블록이 되지 못한다. 그중 가끔 네트워크의 더 어려운 조건까지 충족하는 결과가 나온다.</p><p>따라서 셰어는 여러 개를 붙이면 블록이 완성되는 작은 조각이 아니다. 같은 탐색 과정에서 나온, 검증 가능한 결과다. 초기 포럼에서는 채굴자가 당첨된 결과를 가로챌 수 있는지도 논의했다. 풀을 위한 작업에는 보상을 풀로 보내는 거래가 반영되어 있다. 수신 대상을 바꾸면 해시를 계산할 블록 자체가 달라지므로, 이미 찾은 성공한 해시를 그대로 재사용할 수 없다.</p><h2>기다림은 나누고, 책임은 맡기다</h2><p>11월의 포럼 글은 제안이었다. Braiins는 후대 기록에서 2010년 12월 16일을 풀의 운영 시작일로 제시한다. 두 시점을 구분해야 논의를 시작한 날을 서비스가 이미 가동한 날로 바꾸지 않게 된다. 이 풀은 슬러시 풀로, 이후에는 Braiins Pool로 알려졌다. 나중의 보상 체계도 초기의 비례 배분 구상에서 더 발전했다.</p><p>슬러시는 처음부터 대가를 인정했다. 참가자들은 그가 보상을 제대로 나눠줄 것이라고 믿어야 했다. 셰어는 누가 얼마나 일했는지 가늠하게 했지만 운영자를 없애지는 않았다. 오래 남은 발상은 작은 채굴자 한 명의 운에 참여가 지나치게 좌우되지 않도록 하자는 것이었다. 그와 함께 남은 질문은 누가 장부를 관리하고 각자의 몫을 지급하느냐였다.</p><h2>출처</h2><ul><li><a href="https://bitcointalk.org/index.php?topic=1976.0">Slush and ribuck: Cooperative mining discussion</a></li><li><a href="https://developer.bitcoin.org/devguide/mining.html">Bitcoin Developer Guide: Mining</a></li><li><a href="https://braiins.com/blog/bitcoin-mining-pools-luck-shares-estimated-hashrate">Bitcoin Mining Pools: Luck, Shares, and Estimated Hashrate Explained</a></li><li><a href="https://braiins.com/blog/hashrate-as-a-commodity-bitcoin-mining-pools">Hashrate as a commodity: the endgame of bitcoin mining pools</a></li><li><a href="https://braiins.com/blog/hashing-history-the-story-of-braiins">Hashing History: The Story of Braiins</a></li></ul>]]></content:encoded>
  </item>
    <item>
    <title>Brave — 광고를 고르는 곳은 내 브라우저</title>
    <link>https://coinyq.com/ko/stories/brave-bat-private-ads-local-matching</link>
    <guid isPermaLink="true">https://coinyq.com/ko/stories/brave-bat-private-ads-local-matching</guid>
    <pubDate>Fri, 18 Sep 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[2019년 Brave는 광고를 켜면 BAT로 보상하겠다고 제안했다. 그 뒤에는 광고 목록을 브라우저로 가져와 기기 안에서 고르는 구조가 있었다. 광고 선택, 성과 보고, 보상 인출은 서로 다른 문제였다.]]></description>
    <content:encoded><![CDATA[<p><img src="https://coinyq.com/stories/brave-bat-private-ads-local-matching.webp" alt="Brave — 광고를 고르는 곳은 내 브라우저" /></p><p>2019년 Brave는 광고를 켜면 BAT로 보상하겠다고 제안했다. 그 뒤에는 광고 목록을 브라우저로 가져와 기기 안에서 고르는 구조가 있었다. 광고 선택, 성과 보고, 보상 인출은 서로 다른 문제였다.</p><h2>사용자가 초대해야 나타나는 광고</h2><p>2019년 4월 24일, Brave는 데스크톱 브라우저에 조금 낯선 선택지를 넣었다. 사용자가 광고를 켤 수 있게 한 것이다. 회사는 이미 추적기와 그에 딸린 광고를 기본으로 차단하고 있었다. 새 광고는 이와 별개의 선택형 서비스로, 알림 형태로 전달됐다. 알림을 누르면 광고 탭이 열렸다. 읽고 있는 페이지의 모든 배너를 다른 광고로 갈아 끼우는 방식은 아니었다.</p><p>제안에는 수익 배분이 들어 있었다. Brave는 이 광고의 총수익 가운데 70%를 베이직 어텐션 토큰(BAT)으로 이용자에게 돌려주겠다고 밝혔다. 보상은 월별 주기로 처리되며 매체와 창작자를 후원하는 데 쓸 수 있었다. 70%는 수익을 나누는 비율이지 브라우저를 켜두면 받는 고정 수입이 아니었다. 출시 발표에서 개인 용도로 보상을 인출하는 기능은 아직 개발 중인 것으로 설명됐다.</p><h2>광고 목록을 독자에게 가져오다</h2><p>더 흥미로운 변화는 광고를 고르는 장소였다. Brave의 2020년 9월 기술 설명에 따르면, 브라우저는 국가별로 제공되는 광고 캠페인 목록을 주기적으로 내려받았다. 그런 다음 기기에 있는 정보를 바탕으로 그중 하나를 골랐다. 다음 광고를 서버가 고르게 하려고 개인의 브라우징 기록을 광고 서버로 보낼 필요가 없도록 한 구조였다.</p><p>개인화 자체가 사라진 것은 아니었다. 기기 안의 신호로 관련성과 표시 시점을 판단했다. 프라이버시가 모두에게 똑같은 무작위 광고를 보여준다는 뜻은 아니었다. 범용 모델은 별도로 훈련한 뒤 브라우저에 내려보내 사용했다. 기술 문서는 이메일이나 소셜 미디어처럼 로그인이 필요한 사이트에서 관심사를 추론하지 않는다고도 설명했다. 이는 당시 시스템에 관한 개발사의 설명이며, 브라우저가 사람의 모든 취향을 안다는 주장은 아니다.</p><h2>보상에는 광고 선택 이상의 일이 필요했다</h2><p>BAT가 맡은 것은 배분에 관한 역할이었다. 이용자가 주의를 기울인 대가로 무엇을 받고, 그중 무엇을 창작자에게 보낼 수 있는가 하는 문제다. 자전거와 헤드폰 중 어느 광고가 적절한지를 토큰 자체가 결정하지는 않았다. 광고 선택은 브라우저 소프트웨어의 일이었다. 이 역할을 구분하면 광고에 토큰을 붙이는 것만으로 브라우징 데이터가 보호되지는 않는다는 점도 분명해진다.</p><p>광고주에게는 여전히 광고 활동의 증거가 필요했다. Brave의 2020년 설명은 노출·클릭·전환 보고의 프라이버시를 지키고 서로 연결되지 않게 하려는 Privacy Pass 기반의 별도 프로토콜을 소개했다. 기기 안에서 광고를 고른다고 해서 브라우저가 서비스와 전혀 통신하지 않는 것은 아니었다. 광고 목록 전달, 선택, 보고마다 설계가 필요했다. 문서 역시 당시 플랫폼을 신뢰가 완전히 불필요한 완성품이 아니라 더 나아갈 단계로 설명했다.</p><h2>보상을 꺼내는 문에는 다른 절차가 있었다</h2><p>2019년 10월 3일, Brave는 데스크톱 0.69 버전에서 인증 절차를 거친 Uphold 계정으로 획득한 BAT를 옮길 수 있게 됐다고 발표했다. 릴리즈 노트에도 양방향 지갑이 명시됐다. 이전의 후원 중심 지갑에서 달라진 실제 기능이었다. 보상이 브라우저의 창작자 후원 흐름에만 머무르지 않고 금융 파트너를 거쳐 밖으로 나갈 길이 생겼다.</p><p>당시 Rewards 팀은 보상을 받고 사이트나 채널에 돌려주는 데 인증이 필수는 아니라고 강조했다. 새 인출 경로를 쓰는 것은 별도의 선택이었으며 신원 확인 절차가 있었다. 이 경계를 나누면 모순처럼 보이던 부분도 이해할 수 있다. 브라우징 기록을 내보내지 않고 광고를 고르는 일과 인증 계정으로 보상을 인출하는 일은 서로 다른 문제를 푼다. Brave의 초기 실험은 독자의 관심뿐 아니라 보상을 어디로 보낼지도 독자의 선택으로 만들었다.</p><h2>출처</h2><ul><li><a href="https://brave.com/blog/brave-ads-launch/">Brave Ads launch announcement</a></li><li><a href="https://brave.com/blog/intro-to-brave-ads/">An Introduction to Brave’s In-Browser Ads</a></li><li><a href="https://brave.com/blog/brave-partners-with-uphold-to-launch-wallet-that-rewards-users-for-browsing/">Brave and Uphold: two-way Rewards wallets</a></li><li><a href="https://community.brave.app/t/release-channel-v0-69-132/85880">Release Channel v0.69.132</a></li><li><a href="https://community.brave.com/t/release-0-69-brings-2-way-user-wallets-to-brave-rewards/85888">Rewards team: Release 0.69 brings two-way wallets</a></li></ul>]]></content:encoded>
  </item>
  </channel>
</rss>