We are hosting a developer all-day event in Berlin on November 19th, 2019. Learn how to build blockchain applications, participate in coding challenges, educational blockchain talks, and an afterparty! Grab your free ticket here.
The month of October saw our developer teams progress with the SDK and the Lisk Builders get with experimenting with our toolkit. There are also some exciting news from our UI team for hardware wallet fanatics. Here are the main takeaways:
The main features include the following Lisk Improvement Proposals:
Our QA process has started, and our focus has now switched to improving tests, identifying implementation details deviated from the LIPs, and doing some small refactoring.
LIP-0009 was completed and included in SDK 3.0.0. This LIP proposes to mitigate transaction replay on different chains by introducing a network identifier as a constitutive component of the signature of a transaction.
LIP-0012 has been completed and included in SDK 3.0.0 as well. The current protocol allows for, and partially enforces, the usage of property-value pairs in transaction objects that are neither required nor used. These property-value pairs are contained in the JSON objects used to transmit transactions and in the input messages for the transaction signature and the transaction ID generation. This increases the size of transactions and the complexity of the protocol unnecessarily. Therefore, this LIP proposes to remove these redundant properties from transaction objects.
The first is triggered when a block is received and the difference in block slots between itself and the finalized block slot of the system is bigger than the number of delegates multiplied by 3 (303). The process of syncing is easy: the best peer out of the list of connected peers is computed according to the peer selection algorithm mentioned in LIP-0014 and blocks are requested to that peer and applied in chunks. The second, Fast Chain Switching mechanism is triggered when the difference in height between block received from the network and the latest block that node has is smaller than the number of delegates multiplied by two (202). Once triggered, blocks are requested and validated. If all of them are valid, the blocks are applied. This will allow nodes which are slightly behind on height or in a fork state, to catch up with the network faster than the block synchronization mechanism.
PS: Always use third party tools with caution.
We are happy to announce that our desktop application is able to support another member of the Trezor family, Trezor One. This is the fourth hardware wallet supported by Lisk Hub, after Ledger Nano S, Ledger Nano, X and Trezor Model T. You can read more about this implementation in our previous Development Update.
After the latest refactor made in our hardware wallet module, it was pretty straightforward to add support for Trezor One. The only specific of this hardware wallet is how the device is unlocked by PIN. All the previously supported models handle entering PIN by their own buttons or touch screen and don’t require any support in the desktop app for unlocking the device. If the device is locked, it doesn’t even show up on Hub. Trezor One, however, uses a blind metrix (for more info see official Trezor docs here) for entering the PIN.
Same as the other hardware wallets you can ‘Sign In’ with your Trezor One, selecting the option ‘Sign In’ with Hardware Wallet from the ‘Sign In’ page.
Then you will see the the new page with the matrix screen to introduce your Trezor One pin.
After you unlock your Trezor One device, you will see the available accounts in the next screen.
After you select the account that you want to sign in to, you will be able to access and manage your tokens via Hub. In the confirmation page, you will always need to use your Trezor One device to confirm or reject that transaction.
The new version of Lisk Hub enable you to sign a random message. One of the benefits of this feature is to prove the ownership of your account. This feature was available in Lisk Hub but there was no screen to enable users to validate signed messages and users had to do so using our old wallet, Lisk Nano, or other tools developed and maintained by other community members. With this release, we have added a screen dedicated to verifying messages which are signed as mentioned above. You can access this screen through a launch protocol: `Lisk://sign-message`. Simply click on this link and, if Lisk Hub is installed on your computer, it’ll run the app, and open the sign message page. You can input any string/message and the output will be similar to the following screen:
Similarly for verifying a signed message, you can click on `Lisk://verify-message `. There are two options: you can either enter the entire message generated by Lisk Hub in a single input:
Or you can enter the values individually:
Choose one of the methods, fill in your information accordingly and press continue — Lisk Hub will determine if the message was signed by the owner of the account whose public key is included in this signed message or not. If successful, your screen should display this:
PS: With the next release, we are dropping ‘Hub’ in the name. Our desktop app will simply be called Lisk.
If you use Lisk Hub, we would really appreciate if you activate this feature to help us constantly improve your experience of our wallets in the future.
In October, we have expanded our testing efforts with the help of visual testing. The idea is to capture DOM snapshots and assets for the specific screens during our testing process and send them to a visual testing provider to render screenshots. Screenshots are then compared with the latest approved ones. In case there are any differences in pixel-by-pixel comparison, we get a warning meaning layout or styles were changed. There are a variety of tools to fulfill visual testing and we are using Percy. Bellow you can see a screenshot which demonstrates Percy capturing an unintended change in our generic style rules which affected basic HTML elements:
We should either approve changes or raise our attention and identify the code that caused unintended effects. This approach compliments our functional testing and helps to eliminate visual defects.
We have added Swiss Franc (CHF) to the list of supported fiat currencies on Lisk Hub. before this, we were only supporting Euro and USD. We added CHF because Lisk project is developed by a Switzerland-based Foundation and we have many users from that region. You can choose the Swiss Franc as your default currency in Setting pages. After that you will be able to choose your desired fiat currency converter in the transaction page.
Lisk Development Team
Lisk is on a mission to enable you to create decentralized, efficient, and transparent blockchain applications. Join us:
SDK 3.0.0 Development Complete and New Proof-of-Concepts was originally published in Lisk Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
Muy buena publicación https://www.bestbloger.com
Community | 캐스트윗 (CTT) 5월 일정 살펴보기
Sehr guter Beitrag
Community | 캐스트윗 (CTT) 5월 일정 살펴보기
Community | 오늘도 코고 퀴즈 풀고 GST 받아요
여기에서 내가 원하는 대한 조언을 오랜 시간: 한국 뒤로 가기 저를 믿고,최고의 사이트를 찾을 수 없습니다,나는 매우 행복으로 무슨 일이 있었는지 지금 나는 확실히 노력하겠습니다.어떤 경우에는 경우에 당신은 당신의 필요성에 직면하고 최적화를 위해,당신은 여기에서
Community | 멀티 브로드캐스트 플랫폼, 캐스트윗 (CTT)
잘봤오요~~~~~저도 이거 참여하고 있어요!
Community | 리버마운트(RM) 상장 및 IEO 전 라스트 에어드랍 이벤트!!!
Write a post
Are you sure you want to delete this post?
Are you sure you want to delete this comment?
Purchase has been completed.
닉네임을 설정 후 작성해주세요.