BLS 서명과 장점은 무엇입니까?

BLS 시그니처는 컴팩트 한 집계 가능한 디지털 시그니처에 이중선 쌍을 사용하여 블록 체인 및 암호 화폐 응용 프로그램의 효율성을 향상시킵니다.

2025/04/11 05:00

BLS (Boneh-Lynn-Shacham) 시그니처는 암호화에서 이중선 페어링을 활용하는 디지털 서명 체계의 한 유형입니다. 발명가 인 Dan Bone, Ben Lynn 및 Hovav Shacham의 이름을 따서 명명되었습니다. BLS 서명은 특히 고유 한 특성과 장점으로 인해 암호 화폐 및 블록 체인 공간에서 가치가 있습니다. 이 기사에서는 BLS 서명이 무엇인지, 작동 방식 및 Cryptocurrency 생태계 내에서 제공하는 특정 이점을 살펴 봅니다.

BLS 서명이란 무엇입니까?

BLS 서명은 이중선 쌍을 사용하는 암호화 서명 유형이며, 이는 한 그룹에서 두 가지 요소를 가져와 다른 그룹의 요소에 매핑하는 수학 연산입니다. 이 속성을 사용하면 BLS 시그니처가 ECDSA (Elliptic Curve Digital Signature Algorithm)와 같은 기존 시그니처 체계에서는 불가능한 특정 효율성 및 기능을 달성 할 수 있습니다.

BLS 시그니처의 핵심 아이디어는 이러한 이중선 페어링을 사용하여 짧고 검증 가능한 서명을 만드는 것입니다. BLS 시그니처는 일반적으로 단일 그룹 요소로 구성되므로 다른 서명 체계보다 훨씬 작습니다. 이 작품은 특히 대역폭과 스토리지가 프리미엄 인 환경에서 BLS 시그니처의 주요 장점 중 하나입니다.

BLS 서명의 작동 방식

BLS 서명의 작동 방식을 이해하려면 이중선 쌍의 개념을 파악하는 것이 중요합니다. 이중선 쌍은 함수 E : G1 X G2 → GT이며, 여기서 G1, G2 및 GT는 그룹이며 E는 특정 특성을 만족시킵니다. BLS 서명의 맥락에서, 이들 그룹은 일반적으로 타원 곡선 그룹이다.

BLS 서명을 생성하고 확인하는 프로세스에는 다음 단계가 포함됩니다.

• 키 생성 : 서명자는 개인 키 SK와 해당 공개 키 PK를 생성합니다. 개인 키는 그룹 G1의 임의 요소이며 공개 키는 G2의 발전기 지점을 사용하여 개인 키에서 파생됩니다.
• 서명 : 메시지 M에 서명하기 위해 서명자는 메시지를 G1의 한 지점으로 해시 한 다음이 지점에 개인 키를 곱합니다. 결과는 BLS 서명입니다.
• 검증 : 서명을 확인하기 위해 검증기는 G2의 서명과 생성기 지점의 이중선 쌍을 계산하고 해시 메시지 및 공개 키의 이중선 페어링과 비교합니다. 두 페어링이 같으면 서명이 유효합니다.

이 프로세스는 이중 선형 페어링의 특성을 활용하여 서명이 안전하고 효율적인지 확인합니다.

cryptocurrency에서 BLS 서명의 장점

BLS 시그니처는 암호 화폐 및 블록 체인 공간에서 특히 매력적으로 만드는 몇 가지 장점을 제공합니다.

• 짧은 서명 : 앞에서 언급했듯이 BLS 서명은 매우 작습니다. 이는 트랜잭션 및 블록의 크기를 줄여 스토리지 및 대역폭 요구 사항을 낮추기 때문에 모든 바이트가 계산되는 블록 체인 시스템에서 중요합니다.
• 집계 : BLS 시그니처의 가장 강력한 특징 중 하나는 집계 능력입니다. 다중 BLS 시그니처는 단일 서명만큼 짧은 단일 서명으로 결합 할 수 있습니다. 이는 여러 당사자가 다중 서명 지갑 또는 크로스 체인 거래와 같은 단일 메시지에 서명 해야하는 시나리오에서 특히 유용합니다.
• 효율적인 검증 : BLS 서명을 집계하더라도 효율적으로 검증 할 수 있습니다. 이는 검증자가 최소한의 계산 오버 헤드로 많은 수의 서명을 점검 할 수 있음을 의미합니다. 이는 블록 체인 네트워크를 스케일링하는 데 유리합니다.
• 보안 : BLS 서명은 타원 곡선 그룹의 개별 로그 문제의 경도를 기반으로하며, 이는 높은 수준의 보안을 제공합니다. 또한, 이중선 쌍을 사용하면 추가 보안 계층이 추가되어 BLS 시그니처가 다른 시그니처 체계가 취약 할 수있는 특정 유형의 공격에 저항 할 수 있습니다.

cryptocurrency에서 BLS 서명의 사용 사례

BLS 서명은 cryptocurrency 생태계 내에서 여러 응용 프로그램을 발견했습니다.

• 이더 리움 2.0 : 이더 리움의 이더 리움 2.0으로 알려진 스테이크 증명 컨센서스 메커니즘으로의 전환은 유효성 검사기 증명에 BLS 서명을 활용합니다. BLS 시그니처의 집계 기능은 여러 증명을 효율적으로 검증 할 수 있으며, 이는 네트워크의 확장성에 중요합니다.
• 다중 서명 지갑 : BLS 서명은 여러 당사자가 거래에 서명 해야하는 다중 서명 지갑에 이상적입니다. 서명을 집계하는 능력은 여러 서명이 있어도 거래 크기가 작은 상태로 유지됨을 의미합니다.
• 크로스 체인 트랜잭션 : 다른 블록 체인 네트워크에서 트랜잭션을 검증 해야하는 시나리오에서 BLS 서명을 사용하여 여러 체인에서 서명을 효율적으로 집계하여 검증 프로세스를 단순화 할 수 있습니다.

cryptocurrency 프로젝트에서 BLS 서명 구현

cryptocurrency 프로젝트에서 BLS 서명을 구현하려는 개발자의 경우 다음 단계를 따를 수 있습니다.

• 라이브러리 선택 : BLS12-381 라이브러리와 같은 BLS 서명을 지원하는 몇 가지 암호화 라이브러리가 있습니다. 잘 관리되고 프로젝트의 프로그래밍 언어와 호환되는 라이브러리를 선택하십시오.
• 키 생성 : 라이브러리를 사용하여 개인 및 공개 키를 생성하십시오. 키가 안전하게 저장되고 관리되어 있는지 확인하십시오.
• 메시지 서명 : 서명 함수를 구현하여 메시지에 대한 BLS 서명을 생성합니다. 여기에는 메시지를 해시하고 개인 키로 곱하는 것이 포함됩니다.
• 서명 확인 : 확인 기능을 구현하여 BLS 서명의 유효성을 확인하십시오. 여기에는 bilinear 페어링을 계산하고 비교하는 것이 포함됩니다.
• 집계 서명 : 사용 사례에 필요한 경우 집계 함수를 구현하여 여러 BLS 서명을 단일 서명으로 결합하십시오.

도전과 고려 사항

BLS 서명은 많은 장점을 제공하지만 명심해야 할 몇 가지 과제와 고려 사항도 있습니다.

• 복잡성 : BLS 시그니처 뒤에있는 수학은 복잡 할 수 있으며,이를 올바르게 구현하려면 타원 곡선 암호화 및 이중 선형 페어링에 대한 깊은 이해가 필요합니다.
• 성능 : BLS 서명은 크기 및 검증 측면에서 효율적이지만 실제 성능은 구현 및 사용 된 하드웨어에 따라 다를 수 있습니다. 개발자는 최고의 성능을 달성하기 위해 코드를 최적화해야합니다.
• 보안 : BLS 서명은 안전하지만 모든 유형의 공격에 면역되지는 않습니다. 개발자는 최신 암호화 연구에 대한 업데이트를 유지하고 알려진 취약점에 대해 구현이 안전해야합니다.

자주 묻는 질문

Q : 기존 블록 체인 네트워크와 함께 BLS 서명을 사용할 수 있습니까?

A : 그렇습니다. BLS 서명은 기존 블록 체인 네트워크에 통합 될 수 있지만 신중한 계획 및 구현이 필요합니다. 예를 들어, Ethereum 2.0은 유효성 검사기 증명을 위해 BLS 서명을 성공적으로 통합했습니다. 그러나 전환은 네트워크의 합의 메커니즘 및 검증 프로세스에 대한 업데이트가 필요할 수 있습니다.

Q : BLS 서명은 모든 유형의 암호 화폐와 호환됩니까?

A : BLS 시그니처는 대부분의 크립토 화폐와 호환되지만 특정 구현은 cryptocurrency의 기본 암호화 인프라에 따라 다를 수 있습니다. 예를 들어, 다른 타원 곡선 그룹을 사용하는 cryptocurrencies는 BLS 시그니처 체계에 대한 조정이 필요할 수 있습니다.

Q : BLS 서명은 ECDSA와 같은 다른 서명 체계와 어떻게 비교됩니까?

A : BLS 서명은 서명이 짧고 여러 서명을 집계하는 능력을 포함하여 ECDSA에 비해 몇 가지 장점을 제공합니다. 그러나 ECDSA는 더 널리 사용되고 이해되며 구현은 종종 더 간단합니다. BLS와 ECDSA 사이의 선택은 집계의 필요성 및 서명 크기의 중요성과 같은 프로젝트의 특정 요구 사항에 따라 다릅니다.

Q : cryptocurrency에서 BLS 시그니처를 사용할 수있는 잠재적 위험은 무엇입니까?

A : BLS 시그니처와 관련된 주요 위험에는 구현의 복잡성이 포함되어 있으며, 이는 올바르게 수행하지 않으면 오류로 이어질 수 있으며 기본 암호화 가정의 잠재적 취약점. 개발자는 이러한 위험을 완화하기 위해 구현이 안전하고 정기적으로 업데이트되도록해야합니다.