마시멜로

● 구성
1. 번역본
2. 원문






1. 번역본


Hyperledger 패브릭 v1.4의 새로운 기능 
---- --------------------------------- 

이 릴리스에는 다음 기능이 포함되어 있습니다. 

패브릭 운영 서비스 
새로운 HTTP 기반 " 운영자 "엔드 포인트가 주문자 및 
피어 에 구현되었습니다 . 엔드 포인트는 API를 사용하여 서버의 상태를 확인하고 
프로세스의 로깅 수준 을 쿼리 및 수정하며 구성시 
Fabric 메트릭 을 노출 합니다. 

FAB-3388 - 패브릭 구성 요소 
의 작동 메트릭 피어 및 발주자는 기본 운영 
메트릭 을 제공하도록 계측되었습니다 . 측정 기준은 Prometheus 또는 StatsD가 소비하도록 나타낼 수 있습니다. 

FAB-10851 - 상태 확인 엔드 포인트
이제 주문자와 피어 
는 HTTP 요청을 통해 프로세스 의 상태를 확인하는 메커니즘을 제공합니다 . 
서버가 정상이라고 판단되면 조작 엔드 포인트 에서 GET / healthz 요청이 200 OK로 완료됩니다 
. 상태 검사가 실패하면 서버는 503 Service 
Unavailable 및 문제를 발견 한 구성 요소를 나타내는 JSON 페이로드로 응답 합니다. 
수행되는 건강 검진의 유형은 시간이 지남에 따라 연장됩니다. 

FAB-12265 - 동적 로그 레벨 
이제 주문자와 피어 
는 서버 의 활성 로그 스펙 을 가져오고 갱신하는 메커니즘을 제공 합니다. 
작업 끝점 에서 GET / logspec에 대한 요청 은 활성 끝 점이 포함 된 JSON 페이로드로 반환됩니다.
투기. `{ "spec": "the-log-spec"} "의 JSON 페이로드가 
PUT / logspec 요청 의 본문으로 전송 되면 활성 로깅 스펙이 업데이트됩니다. 

FAB-12357 - 로깅 업데이트 
이전 버전의 Fabric에서는 로거가 명명 된 구성 요소 
와 연결되어 있으며 구성이 각 로거의 활성 레벨을 제어합니다. 이 
모델은 이론적으로는 작동 하지만 
Fabric에서 사용하는 구성 관리 라이브러리 와 Fabric 코드 기반의 구조 때문에 실제로는 
여러 가지 문제가있었습니다. 
1.4에서는 모델을 약간 변경합니다. 로거 
와 구성 요소 를 연결하는 대신 로거의 이름을 지정하고 그 동안 부작용을 피하는 데 도움을줍니다.
로깅 구성은 더 이상 
패브릭 구성 시스템 에서 가져 오지 않고 
로깅 사양 및 로그 형식 을 정의 하는 환경 변수에서 가져옵니다 . 
로그 스펙은 콜론으로 구분 된 
토큰으로 구성된 단일 문자열입니다 . 각 토큰은 하나 이상의 로거 이름 접두어 ( 
쉼표로 구분)와 선택적 로그 레벨을 선언 합니다. 로거 이름 접두사가 
마침표로 끝나면 마침표가 
없는 정확한 이름 의 로거에만 로그 수준이 적용되어야 함을 나타냅니다 . 로거 이름 패턴이 
생략되면 기본 로그 레벨을 지정합니다. 여러 항목 
이 동일한 이름 패턴을 참조하거나 여러 인스턴스가 기본값 인 경우
제공되면 마지막 사양이 우선 적용됩니다. 

FAB-12363 - gRPC 상호 작용을 
위한 로깅 이제 주문자와 피어는 
완료된 각 gRPC 상호 작용에 대한 로깅 (INFO 레벨)을 제공 합니다. 

FAB-12372 - 종료없이 루틴 스택 가져 오기 
피어 또는 주문자가 SIGUSR1을 수신하면 모든 이동 
루틴 의 상태 가 캡처되어 INFO 수준에서 기록됩니다. 이 수집 
활동은 프로세스를 종료하지 않습니다. 

FAB-5093 - 개인 데이터 조정 
개인 데이터 수집 
에 추가 된 조직의 동료가 현재 
자격 이있는 이전 트랜잭션의 개인 데이터를 검색 할 수 있습니다 . 이 기능은 가입 한 동료에서만 지원됩니다.
v1.4 이후의 채널. 

FAB-11409 - 개인 데이터 클라이언트 액세스 제어 
특정 체인 코드 로직 
을 작성할 필요없이 클라이언트 조직 콜렉션 멤버십을 
기반 으로 체인 코드 내에서 자동으로 액세스 제어를 수행 할 수있는 기능 . 이 기능은 
collection 구성 등록 정보 memberOnlyRead : true 를 사용하여 구성됩니다 . 
v1.4 피어 및 이전 릴리스 피어의 혼합 네트워크 가 있는 경우 이전 
피어는 
v1.4 로 업그레이드 될 때까지이 구성을 따르지 않습니다 . 

변경 사항, 알려진 문제점 및 해결 방법 
-------------------------------------- 

FAB-12357 - 업데이트 to logging 로깅 
을 제어하기 위해 logging.level 및 CORE_LOGGING_LEVEL을 사용하는 대신
레벨, General.LogLevel 또는 ORDERER_GENERAL_LOGLEVEL을 
사용하여 순서 지정자에서 로깅 을 제어하면 이제 두 프로세스 모두 FABRIC_LOGGING_SPEC 
환경 변수를 사용 하여 
서버에 대한 초기 로깅 스펙을 확보 합니다. 기존 로깅 구성을 새 모델로 변환해야합니다. 

FAB-12489 - 피어 로깅 명령 업데이트 
`peer 
logging` 명령 의`getlevel`,`setlevel` 및`revertlevels` 부속 명령은 더 이상 사용되지 않으며 사용자는 운영 
서버 로 마이그레이션해야 합니다. 
`setlevel`의 동작 또한 약간 변경되었습니다. 이전의 
구현은`logger` 인수를 정규 표현식으로 취급하고 
새로운 로그 레벨을 표현식과 일치하는 모든 로거에 적용합니다. 그만큼
갱신 된 구현은`logger` 인수를 로거 이름으로서 취급 해 
, 지정된 레벨의 액티브 로깅 스펙에 추가합니다. 

FAB-12088 - s390 아키텍처에서의 
Java 체인 코드 지원 s390 아키텍처 에서는 아직 Java 체인 코드 지원을 사용할 수 없습니다. 

FAB-12134 지문 불일치 오류를 수신하는 동일한 체인 코드 소스 
다른 방법으로 설치된 체인 코드 
는 인스턴스화시 "체인 코드 지문 불일치 데이터 불일치"오류를 초래할 수 있습니다 . 이 문제는 
서로 다른 SDK를 사용하여 체인 코드를 설치하는 경우 발생할 수 있습니다 . 이 문제를 해결하려면 
"peer chaincode package"명령 
을 사용하여 설치 및 인스턴스화 전에 chaincode를 패키지화하십시오. 

알려진 취약점 
---------------------
FAB-8664 - 조직이 제거되었을 때 피어가 감지하고 대응해야 함 
이것은 
네트워크 관리자 의 중요한 음모가 필요하기 때문에 상대적으로 심각도가 낮은 문제 이지만 향후 릴리스에서 해결 될 것입니다. 

해결 된 취약점 
------------------------ 
없음. 

기타 향상된 기능 및 수정 사항 
---------------------------- 
Go 버전 1.11.1로 
업데이트되었습니다. 기본 이미지 버전을 0.4.14로 업데이트했습니다 

. 전체 목록 개선 및 수정에 대한 내용은 릴리스 변경 로그를 참조하십시오. 
https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v140

2. 원문

What's New in Hyperledger Fabric v1.4
-------------------------------------

The following features are included in this release:

Fabric operations service
A new HTTP based "operations" endpoint has been implemented on the orderer and
the peer. The endpoint exposes APIs to check the server's health, to query
and modify the logging level of the process, and, when configured, to expose
Fabric metrics.

FAB-3388 - Operational metrics for Fabric components
The peer and orderer have been instrumented to provide basic operational
metrics. The metrics can be surfaced for consumption by Prometheus or StatsD.

FAB-10851 - Health check endpoint
The orderer and the peer now provide a mechanism to check the health of the
process via an HTTP request. Requests to GET /healthz on the operations
endpoint will complete with a status 200 OK when the server believes it is
healthy. When a health check fails, the server will respond with a 503 Service
Unavailable and a JSON payload indicating which component detected an issue.
The types of health checks that are performed will be extended over time.

FAB-12265 - Dynamic log levels
The orderer and the peer now provide a mechanism to get and update the active
logging specification of the server. Requests to GET /logspec on the
operations endpoint will return with a JSON payload that contains the active
spec. When a JSON payload of `{"spec":"the-log-spec"}` is sent as the body of
a PUT /logspec request, the active logging spec will be updated.

FAB-12357 - Updates to logging
In earlier versions of Fabric, loggers were associated with named components
and configuration would control the active level of each logger. While this
model works in theory, because of the configuration management libraries used
by Fabric and the structure of the Fabric code base, in practice it had a
number of issues.
With 1.4, we're changing the model slightly. Instead of associating loggers
with components, we are naming loggers and to help avoid side effects during
initialization, the logging configuration is no longer obtained from the
fabric configuration system but from environment variables that define
the logging specification and log format.
The log specification is a single string that consists of colon separated
tokens. Each token declares one or more logger name prefixes (separated by
commas) and an optional log level. When the logger name prefix ends with a
period, it indicates that the log level should only apply to the logger with
that exact name without the trailing period. When the logger name pattern is
omitted, it specifies the default log level. In cases where multiple entries
reference the same name pattern or multiple instances of a default are
provided, the last specification takes precedence.

FAB-12363 - Logging for gRPC interactions
The orderer and the peer now provide logging (INFO level) for each gRPC
interaction completed.

FAB-12372 - Obtain Go routine stacks without termination
When SIGUSR1 is received by the peer or the orderer, the state of all go
routines will be captured and logged at the INFO level. This collection
activity will not terminate the process.

FAB-5093 - Private data reconciliation
Allows peers for organizations that are added to private data collections
to retrieve the private data for prior transactions to which they now are
entitled. This feature is only supported on peers that have joined
a channel since v1.4.

FAB-11409 - Private data client access control
Ability to automatically enforce access control within chaincode based
on the client organization collection membership without having to
write specific chaincode logic. This feature is configured by using
the collection configuration property memberOnlyRead:true. If you have
a mixed network of v1.4 peers and prior release peers, the prior
release peers will not honor this configuration until they are upgraded
to v1.4.

Changes, Known Issues, and Workarounds
--------------------------------------

FAB-12357 - Updates to logging
Instead of using logging.level and CORE_LOGGING_LEVEL to control the logging
level for the peer, and General.LogLevel or ORDERER_GENERAL_LOGLEVEL to
control logging at the orderer, both processes now use the FABRIC_LOGGING_SPEC
environment variable to acquire the initial logging specification for the
server. Existing logging configuration should be converted to the new model.

FAB-12489 - peer logging command updates
The `getlevel`, `setlevel`, and `revertlevels` subcommands of the `peer
logging` command are deprecated and users should migrate to the operations
server.
The behavior of `setlevel` has also changed slightly. The previous
implementation would treat the `logger` argument as a regular expression and
apply the new log level to all loggers that matched the expression. The
updated implementation treats the `logger` argument as a logger name and
appends it to the active logging spec at the indicated level.

FAB-12088 - Java chaincode support on s390 architecture
Java chaincode support is not yet available on s390 architecture.

FAB-12134 Same chaincode source receiving fingerprint mismatch error
Chaincode installed in different ways may result in "chaincode fingerprint
mismatch data mismatch" error upon instantiation.  This may happen when
installing chaincode by using different SDKs. To workaround the problem,
package the chaincode prior to installation and instantiation, by using
the "peer chaincode package" command.

Known Vulnerabilities
---------------------
FAB-8664 - Peer should detect and react when its org has been removed
This is a relatively low severity problem, because it requires a significant
conspiracy of network admins, but it will be addressed in a future release.

Resolved Vulnerabilities
------------------------
None.

Other improvements and fixes
----------------------------
Updated to Go version 1.11.1
Updated baseimage version to 0.4.14

For the full list of improvements and fixes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v140

참고

IBM블록체인 

      - 비즈니스를 위한 블록체인 구축

1. 기본개념

모든 피어가 모든 트랜잭션을 실행하고

원장(ledger)을 유지하고

합의(consensus)를 수행해야 하는

허가형 블록체인 네트워크

                    확장성이 부족

그리고 진정한 프라이빗 트랜잭션(private transactions)과

기밀계약(confidential contracts)을 지원하지 못합니다.

이에 따라 하이퍼레저 커뮤니티는

산업용 블록체인 솔루션을 위해

진정한 모듈 방식의 확장 가능하고

modular

scalable

secure

보안기능을 강화한

fabric v1을 설계

가장 크게 달라진것은

피어가 3개의 고유한 역할을 가진

2개의 개별 런타임으로 분리된다는 것입니다.

양도인, 위임인 그리고 수락인

PEERS           [  ENDORSER , COMMITER  ]

CONSENTERS [ CONSENTER  ]

2. 원리

여러분은 캘리포니아에서 유기농 시장을 운영하고

저는 칠레에 있는 농잡에서

무를 재배한다고 가정해 보겠습니다.

여러분과 저는 다양한 시장, 농장, 운송업체, 은행 간의 트랜잭션을 지원하는

블록체인 네트워크를 사용합니다.

!! 저는 여러분에게 특별 할인 가격으로 무를 판매하기로 했습니다.

하지만 저와 거래를 하는 다른시장에는 계속 표준 가격을 판매해야합니다.

다른 업체에서 우리의 기밀 계약을 실행하거나

계약의 세부 정보를 알아서는 안됩니다.

즉, 계약에 포함되지 않은 업체의 경우

업체의 원장에 이러한 트랜잭션이 표시되면 안됩니다.

fabric v1 이 이 모든 사항을 처리합니다.

제 앱은 멤버십 서비스에서 여러분의 자격증명을 찾은후

우리 피어에만 트랜잭션을 전송합니다.

피어 양쪽에서 결과가 생성됩니다.

BOTH OF OUR PEERS WILL GENERATE A RESULT

이러한 쌍방합의에서는 양쪽에서 같은 결과를 제공해야

트랜잭션이 이루어집니다.

그러나 더 많은 업체가 포함된 트랜잭션에는 다른 규칙이 적용될 수 있습니다.

그런 다음, 피어가 검증된 트랜잭션을 애플리케이션으로 다시 전송하고

애플리케이션은 합의된 클라우드로 주문을 전송하게 됩니다.

그러면 주문 트랜잭션이 다시 피어로 전송되고 원장에 기록됩니다.

하지만 제농장의 무가 여러분의 시장까지 가려면

다른 업체들이 필요합니다.

마켓 -> 은행 -> 운송업체 -> 관세청 -> 농장

누군가는 무를 확인하고 선적 컨테이너에 실어야합니다.

또다른 누군가는 B/L,세관검사, 금융 보험 등을 처리해야합니다.

!! 하지만 이들 대부분은 우리의 특별가격을 알 필요가 없습니다.

이제 우리 트랜잭션이 모든 시장, 농장, 운송업체, 협력업체

전체 공급망을 처리하는 네트워크를 지나간다고 생각해보십시오.

많은 산업에서 요구되는 것과 같은 패턴입니다.

모든 트랜잭션은 중앙기관을 거쳐 진행하지 않고

양측의 비밀협약을 관리해야하는 분야 어디에나 적용할 수 있습니다.

참고 IBM 하이퍼레저

유튜브 -비즈니스를 위한 블록체인 구축