ARK A Platform for Consumer Adoption updated info



  • ARK Rust — A new way to interact with the ARK blockchain

    We are nearing completion of our Software Development Kit (SDK) Roadmap, here is our latest and 16th addition — the Rust SDK.

    We are attempting to make it as easy as possible for developers to jump into blockchain development by incorporating all of the major programming languages that we can. Allowing the Rust programming language to be able to interact with the ARK Blockchain opens up one more additional tool for developers to work with ARK.

    Hundreds of companies, large and small, use Rust in production for a variety of tasks. Those tasks include command line tools, web services, DevOps tooling, embedded devices, audio and video analysis and transcoding, cryptocurrencies, bioinformatics, search engines, Internet of Things applications, machine learning, and even major parts of the Firefox web browser.

    Rust is proving to be a productive tool for collaborating among large teams of developers with varying levels of systems programming knowledge. Low-level code is prone to a variety of subtle bugs, which in most other languages can be caught only through extensive testing and careful code review by experienced developers. In Rust, the compiler plays a gatekeeper role by refusing to compile code with these elusive bugs, including concurrency bugs. By working alongside the compiler, the team can spend their time focusing on the program’s logic rather than chasing down bugs.

    To learn more about Rust visit their site at:  https://www.rust-lang.org/

    Features of Rust

    • zero-cost abstractions
    • move semantics
    • guaranteed memory safety
    • threads without data races
    • trait-based generics
    • pattern matching
    • type inference
    • nominal runtime
    • efficient C bindings

    ARK Rust

    Like all our rewritten SDKs Rust follows SoC (Separation of Concerns) design pattern where we separate Client and Crypto code in 2 libraries.

    With this latest addition we are almost done covering all major programming languages. The last ones on the list are C and C++, which will be done in the upcoming weeks.

    Here are some of our officially supported SDKs:

    If you want to get involved with development be sure to check our GitHub Bounty and our developmental guidelines.

    If you want to dive deeper into Rust and it’s abilities, give the official Rust 2018 book a read at https://doc.rust-lang.org/book/2018-edition/foreword.html



  • Major Mobile Wallet Update — With New Features!

    It has been a few months since our last ARK Mobile Wallet update. Since then, we have been hard at work fixing bugs and developing a huge slate of new features!

    To download the latest version you can follow the notification you will receive from Google Play or App Store that there is a new version available. You can also use the links below for manual update or installation (it might a few hours for update to appear depending on your country and schedule of release from App Store or Google Play):

    Android Jelly Bean devices (4.1 to 4.3.1) are no longer supported as they no longer receive security updates from Google. KitKat support will also be removed in the next iteration of the app since it is now considered deprecated from Google updates.

    Changes in Numbers

    Since our last release of ARK Mobile Wallet on March 12th we had:

    • 23 different developers contributing to the Core.
    • 166 files changed in the Core repository.
    • 233 commits to the Core repository.
    • 1,163 lines of code deleted from the Core.
    • 5,218 lines of code added to the Core.

    New Features

    • Adding ARK-based blockchains to the Mobile Wallet

    A popular request was for the addition of different ARK-based networks to the Mobile Wallet, similar to the current Desktop Wallet. Now, other ARK-based projects can be added from within the mobile wallet! This opens doors for developers to test their custom bridgechains using the mobile wallet. Simply input an IP from one of their node IPs/domains and the wallet will automatically obtain all of the necessary information for you to use that network.

    To add an ARK-based blockchain, first click “Create a new profile”, then “Show Advanced”, “Custom” and “Create”. The same process can be done from the “Settings” screen if you are already logged into a profile. If you previously added a custom network and just want to add a new profile attached to that network, you can select it from the drop-down menu.

    Adding custom network within new profile screen
    • V2 Network Ready

    One of the biggest updates is compatibility with our new Core v2. Also, the new Mobile Wallet is now ready to use with our DevNet network v2! When creating a network it automatically checks if it is v1 or v2 so you can import other V2 ready networks into the mobile app!

    • Dark Mode Option

    A huge request was for dark mode (mostly by Travis, who is a dark theme fanatic). Now, those with sensitive eyes, vampires, metal fans, and followers of the Dark Lord can appreciate even more darkness in their life! Special thanks to our community developer ‘Dated’ for taking the time to incorporate our designer Oleg’s dark theme design.

    You can enable this option under “Settings” by clicking on “Dark Mode” (to switch back to light mode just press again).

    Dark Mode can activated under Settings
    • Validate Passphrase (BIP39) When Importing Account

    When importing your passphrase into the mobile wallet, if you enter a non BIP39 passphrase, you will get an error message if the passphrase or the number of words is invalid. Also, there is now a switch to enter custom (non BIP39) passphrases if you are using a custom based passphrase.

    Improved UI and optional custom BIP39 switch
    • Passphrase BIP39 Word Suggestions

    When importing your passphrase there is now an auto-complete feature that shows possible words from the BIP39 list as you enter characters. Click the word to complete the entry making it easier and less prone to errors when importing passphrases.

    Word suggestions from the BIP39 list
    • Add Optional Amount to Receive Screen

    Pressing the + button in the lower right corner gives you an option to ‘Receive’ ARK by entering how much you want to receive (either in ARK or fiat currency). A QR code with all parameters is automatically generated for you to share with who you are requesting payment from (use the share icon in the upper right corner to share it).

    Request a specific payment amount
    • Generate and Import Passphrase in All Possible BIP39 Languages

    This is a feature that allows you to generate and import passphrases in any language (from the possible languages defined in BIP39 wordlist). This can be selected in ‘Settings’ under ‘Wordlist language’.

    Setting other language passphrase option
    • Allow the User to Hide/Show the Passphrase While Inputting

    Improved security on wallet import by allowing hiding of the passphrase with a hide/show icon option.

    Hide / Show passphrase option

    Other Fixes and UI improvements

    • Changing peer of the network — many users had trouble when trying to switch from a bad peer to a good new one, making them have to clean local storage. This has now been resolved and peer change should work as intended.
    • PIN confirmation added when removing wallet — when removing wallet from the app you are now required to input PIN to confirm removal (note that the passphrase will be deleted from the app as well, so make sure you have it backed up).
    • Add address checks when sending — when sending ARK to another address it now checks if the provided address is in correct form and lets the user know if it is not.
    • Show loading screen— added loading window with the spinner when applicable.
    • Make wallet labels unique & fix bugs — Fixed bug that wallet label was not updated “on same screen” and fixed bug that “address” was returned for wallets.
    • Removing read only wallets — there was an error where you could not remove read only wallets from the app. This has now been resolved.
    • Delete confirmation show contact name — when deleting a contact from the list there is now a confirmation window.
    • Shorten addresses in send transaction input field — when sending ARK the address is now shortened, similar to the explorer so you can check the first and last few characters of the address. This is also done when scanning from QR code.
    • Fixed issue that if you don’t allow the camera the app hangs — if you didn’t give permission to the mobile wallet to use your camera for QR, the app froze. This has now been resolved.
    • Unique profile names — enforces uniqueness of profile names to differentiate them.
    • Remove gray square — in some screens a small gray square was visible at the edge of the screen and has now been removed.
    • Keep wallet name when converting watch-only wallet to full wallet.
    • Clean up style on PIN modal & normalize spacing.
    • Added info that 24 hour price is for BTC and show BTC 24 hour change next to BTC value.

    And numerous other patches, resolved code conflicts and dependencies updates!

    New Languages

    • French
    • Korean
    • Bulgarian
    • Czech
    • Italian
    • Portuguese

    Special thanks to all of the community contributors who made this new wallet a possibility and we hope you’ll continue rocking!

    One of the features we will be working on for the next update is implementing support for Ledger hardware devices on Android. There is currently no Ledger support for iOS as this integration requires an OTG cable, more information can be found here: https://support.ledgerwallet.com/hc/en-us/articles/115005463729-OTG-Kit-adapters-for-your-Ledger-devices

    How Can I Help With Development or Report Issues?

    If you want to help, get involved and earn some extra ARK be sure to give ARK GitHub Development Bounty a read and get coding:

    Follow us on social media ( Twitter | Facebook | Reddit ), join our community ( Slack | Discord ) and stay tuned to our blog on Medium and on Steemit.



  • ARK Core v2 Testing: Dynamic Fees

    Recently, the basic elements of ARK dynamic fees were outlined in the October 2nd blog post. Now, we present a guide for enabling and testing the new fee structure as we delve into the technical side of dynamic fees in the upcoming release of ARK Core v2.

    Dynamic fees allow delegates to set their own minimum acceptable fees for transactions and let users specify the maximum fees they are willing to pay for a transaction. The resultant “marketplace” allows for competition among delegates in setting fees, lets users choose the fee needed for the speed of their transaction, and ultimately keeps fees low for the end user.

    This post goes deeper into the technical aspects of dynamic fees and take a look at dynamic fee files with regard to their setup and testing using the Tester CLI to send custom transactions via shell. Dynamic fee testing can be done right now on DevNet and with this blog post we are officially starting our first targeted testing.

    If you have any questions please join our Slack (#devnet) channel, you will then be able to question ARK developers and request additional guidance if needed.

    Technical Breakdown

    A more detailed technical breakdown is described in the AIP proposal for Dynamic Fees.

    Looking at the inclusion scenario from the node process, the steps are:

    1. Send and process transaction payload from the client/sender

    Figure 1: Sending and processing of transactions on the node

    2. Forger requests transaction from the pool

    When the Forger pulls the transactions from the pool, the transactions are checked to see if they match. Methods are called according to the sequence diagram below.

    Figure 2: Forger requesting transactions from the node

    For example a basic transfer transaction with payload looks like this:

    // dynamic transaction payload
     {
        "verified":true,
        "id":"afaa18bfc29762b7b5172fa1f71ea7471c0d9e6dcf2992638865ecb4b3d1f26b",
        "version":1,
        "timestamp":47674390,
        "senderPublicKey":"03d7dfe44e771039334f4712fb95ad355254f674c8f5d286503199157b7bf7c357",
        "recipientId":"DBm8ZgZvaDhgba9jyFNVwDGD8ysbN3w8Tv",
        "type":0,
        "vendorFieldHex":"5449443a2030",
        "amount":"200000000",
        "fee":"270",
        "signature":"3044022045b1ffc09a0eb03e50b64bb98290308f44b19899014b5d656daf290a95dc174f02200f3b084c79caf02d9338ac89951db7889c899c455195cdfe62167e133d47f4e3",
        "data":{
           "version":1,
           "network":30,
           "type":0,
           "timestamp":47674390,
           "senderPublicKey":"03d7dfe44e771039334f4712fb95ad355254f674c8f5d286503199157b7bf7c357",
           "fee":"270",
           "vendorFieldHex":"5449443a2030",
           "amount":"200000000",
           "expiration":15,
           "recipientId":"DBm8ZgZvaDhgba9jyFNVwDGD8ysbN3w8Tv",
           "signature":"3044022045b1ffc09a0eb03e50b64bb98290308f44b19899014b5d656daf290a95dc174f02200f3b084c79caf02d9338ac89951db7889c899c455195cdfe62167e133d47f4e3",
           "vendorField":"TID: 0",
           "id":"afaa18bfc29762b7b5172fa1f71ea7471c0d9e6dcf2992638865ecb4b3d1f26b"
        }
     }

    Translated to a serialized version of this payload:

    // serialised transaction Transfer
    // serialised.length = 160
    {"serialized":
      {
        "type":"Buffer",
        "data":[255,1,30,0,22,116,215,2,3,215,223,228,78,119,16,57,51,79,71,18,251,149,173,53,82,84,246,116,200,245,210,134,80,49,153,21,123,123,247,195,87,14,1,0,0,0,0,0,0,6,84,73,68,58,32,48,0,194,235,11,0,0,0,0,15,0,0,0,30,72,161,107,90,67,151,232,118,184,105,194,229,52,233,123,39,157,230,102,177,48,68,2,32,69,177,255,192,154,14,176,62,80,182,75,185,130,144,48,143,68,177,152,153,1,75,93,101,109,175,41,10,149,220,23,79,2,32,15,59,8,76,121,202,240,45,147,56,172,137,149,29,183,136,156,137,156,69,81,149,205,254,98,22,126,19,61,71,244,227]
      }
    }

    The length of the serialized transaction is 160 bytes. This length is taken into the calculation formula outlined in the AIP-16 proposal.

    The size of a transaction varies and is related to vendorField size. The transaction type is included in the dynamic fee calculations, since a vote or delegate registration transaction requires more processing power. This is where the dynamicOffset plays a role. Offsets are defined in the network settings (network.json). Default values look like this:

    // Found in networks config folder in crypto/lib/networks
    "dynamicOffsets": {
        "transfer": 100,
        "secondSignature": 250,
        "delegateRegistration": 500,
        "vote": 100,
        "multiSignature": 500,
        "ipfs": 250,
        "timelockTransfer": 500,
        "multiPayment": 500,
        "delegateResignation": 500
     }
    // Fees can be enabled and disabled based on setting below. Meaning that from block 10 onwards 
    // the dynamic fees will be active.
     {
        "height": 10,
        "fees":{
          "dynamic" : true
        }
      }

    Dynamic fee is calculated according to the formula implementation, as can be seen here:

     /** Calculates delegate fee for processing and forging if transaction
      * @param {Number} Fee price per byte in ARKTOSHI as set by forger/delegate in delegate.json setting feeMultiplier
      * @param {Transaction} Transaction for which we calculate dynamic fee
      * @returns {Number} Calculated dynamic fee in ARKTOSHI
      */
      calculateFee (feeMultiplier, transaction) {
        if (feeMultiplier <= 0) {
          feeMultiplier = 1
        }
        // we get the transactions offset for a transaction type and 
        // calculate the dynamic fee based on AIP Formula
        return (this.get(transaction.type) + (transaction.serialized.length)) * feeMultiplier
      }

    And finally, the process of retrieving a transaction from the pool is
    seen in the following code snippet. This code is executed according to
    each transaction before returning to the forger (Figure 2 — Forger requesting transactions from the node), method checkIfDynamicFeeMatch(transactions).


    /**
     * Determine if transaction matches the accepted fee by delegate or max fee set by sender
     * @param {Transaction} Transaction - transaction to check
     * @return {Boolean} matches T/F
     */
     module.exports = (transaction) => {
      const transactionFee = transaction.fee.toNumber()
      const staticFee = feeManager.getForTransaction(transaction)
      const blockchain = container.resolvePlugin('blockchain')
      const feeConstants = config.getConstants(blockchain.getLastBlock().data.height).fees
      if (!feeConstants.dynamic && transactionFee !== staticFee) {
        logger.debug(`Received transaction fee '${transactionFee}' for '${transaction.id}' does not match static fee of '${staticFee}'`)
        return false
      }
      if (feeConstants.dynamic) {
        const calculatedFee = dynamicFeeManager.calculateFee(config.delegates.dynamicFees.feeMultiplier, transaction)
        if (transactionFee < config.delegates.dynamicFees.minAcceptableFee) {
          logger.debug(`Fee declined - Received transaction "${transaction.id}" with a fee of "${transactionFee}" which is below the minimum accepted fee of "${config.delegates.dynamicFees.minAcceptableFee}" by this delegate.`)
          return false
        }
        if (calculatedFee > transactionFee) {
          logger.debug(`Fee declined - Received transaction "${transaction.id}" with a fee of "${transactionFee}" which is below the calculated fee of "${calculatedFee}".`)
          return false
        }
        if (transactionFee > staticFee) {
          logger.debug(`Fee declined - Received transaction "${transaction.id}" with a fee of "${transactionFee}" which is higher than the static fee of "${feeManager.get(transaction.type)}".`)
          return false
        }
        logger.debug(`Transaction "${transaction.id}" accepted with fee of "${transactionFee}". The calculated fee is "${calculatedFee}".`)
      }
      return true
    }

    Help Us Test

    New features and core functionalities were tested by our team internally. However, public testing is essential to review all of the usage scenarios and edges cases from a fresh perspective (developers aren’t always the best testers). Wallets incorporating dynamic fees will be available prior to v2 MainNet release, currently only CLI tools will be available for testing on DevNet.

    Everyone is invited to our DevNet to perform proper testing (join our Slack, channel #devnet) — from dynamic fees to multsig transactions and anything else you can think of. The more we test the better the foundation is for our new Core v2.

    If you find a bug, please provide in-depth and detailed information on our GitHub Core repository (click), where all the instructions are already waiting for you.

    Delegates

    All delegates running nodes will have an option to customize fees in the config file according to the network they are running their node for (eg. DevNet Dynamic Fee configuration file).

    Intro to Core Tester CLI

    ARK Core v2 comes equipped with a built in testing suite. Presuming ARK Commander was used to install Core we can move into the Tester directory:

    cd ~/ark-core/packages/core-tester-cli

    From here you can run commands for sending test transactions across the network. They all have built in validation/tests to make sure the transactions are processed correctly.

    To send one or more transactions, you simply run the commands and adjust the parameters. As you can see, the first command starts the tester and tells it which transaction it will run. The “\” at the end means end line and more parameters (commands) will follow. Each parameter starts with “--” and ends with “\” specifying that there are more parameters coming. When you reach the last parameter there is no “\” at the end. For example to generate 2 transactions you would run the following command:

    ./bin/tester transfer \
    -n 2 \
    --base-url http://167.114.29.34 \
    --passphrase "your 12 word passphrase"

    In the example above, n represents the number of transactions you wish to send, base-url is node IP being broadcasted to (replace that with your Node’s IP) and passphrase is the wallet you wish to send transactions from.

    By executing the command you get the following output in your terminal:

    If we check the transactions in the dexplorer.ark.io we can see that two transactions where confirmed and forged:

    The core-tester-cli package comes with the following commands:

    1. ./bin/tester transfer - Send multiple transactions
    2. ./bin/tester second-signature - Create wallets with second signature
    3. ./bin/tester delegate-registration - Create multiple delegates
    4. ./bin/tester vote - Create multiple votes for a delegate
    5. ./bin/tester multi-signature - Create multiple multi-signature wallets

    The tester-CLI suite stores the address and passphrase of every wallet created in the ~/ark-core/packages/core-tester-cli/test-wallets file. You can open the file simply by opening it with your editor. For example:

    nano ~/ark-core/packages/core-tester-cli/test-wallets

    Our core-tester-cli has some basic help and parameter included. If you write:

    ./bin/tester -h

    You get basic help and if you write:

    ./bin/tester COMMAND NAME -h

    You’ll get more detailed information about parameters and command.

    You can also read the commands and their respected values here:

    https://github.com/ArkEcosystem/core/tree/develop/packages/core-tester-cli/bin/tester#L23

    Setting the dynamic fee parameters in generated transactions

    Each of the commands has a list of parameters (see the link above). One of the parameters allows specification of a custom fee that the user is willing to pay for the processing of the transaction.

    The transfer command contains the option `--transfer-fee` where the exact fee can be specified arktoshi.

    ./bin/tester transfer \
    -n 2 \
    --base-url http://127.0.0.1 \
    --transfer-fee 5000 \
    --passphrase "your 12 word passphrase"

    You can also specify random limits for `--transfer-fee` parameters. For example you can specify a transfer-fee range as follows:

    --transfer-fee 1000–5000

    This will randomly select different values for the fees in the provided range between 1000 and 5000 arktoshi.

    If you are looking at your logs output you will see the following messages:

    Let’s run the following command generating 10 transfer transactions with random fees between 29000 and 50000 arktoshi.

    ./bin/tester transfer \
    -n 10 \
    --base-url http://127.0.0.1 \
    --transfer-fee 29000–50000 \
    --passphrase "your 12 word passphrase"

    In the above example fees will be randomly generated for each of the 10 transactions ranging from 29000–50000 arktoshis. This is great for testing limits and min accepted fees.

    If you are running custom ports for API and P2P you have 2 flags available for that (they are defaulted to 4002 and 4003 as we are running this on devnet):

    --api-port 4003 \
    --p2p-port 4002 \

    How do I set fees for other transaction types in Core Tester CLI?

    Each transaction has its own parameter in the core-tester-cli package. Look at the tester command file where all the parameters are visible. In general, we have the following options for dynamic-fee setup related to different transaction types.

    1. ./bin/tester transfer with parameter --transfer-fee
    2. ./bin/tester second-signature with parameter --signature-fee
    3. ./bin/tester delegate-registration with parameter --delegate-fee
    4. ./bin/tester vote with parameter --vote-fee
    5. ./bin/tester multi-signature with parameter --multisig-fee

    How do I configure my node to accept dynamic fees?

    Last but not least, you need to enable your node (your delegate) to accept dynamic fees. A detailed approach is written in the AIP-16 proposal.

    There are two main steps to configure and enable dynamic fees.

    1. Setting your fee parameters as a delegate

    A delegate can define his formula parameters for feeMultiplier and limit incoming transactions with the minAcceptableFee value. All settings are in ARKTOSHI per byte. Delegate settings can be found in delegates.json.

    Assuming core-commander was used to install core, your network config file can be opened with the following command:

    nano ~/.ark/config/delegates.json

    And there you have options to change feeMultipler or minAcceptableFee.

    “dynamicFees”: {
     “feeMultiplier”: 1000,
     “minAcceptableFee”: 30000
     }

    If you change it don’t forget to restart your Core process to load updated settings.

    2. Turning on dynamic fees

    Turn on dynamic fees in your network configuration file. Assuming core-commander was used to install core, your network config file can be opened with the following command:

    nano ~/.ark/config/network.json

    By setting the value of dynamic to true and defining a new milestone and the block height from which the settings should go into effect, we can enable or disable the dynamic fees on the node level.

    For example the settings below will enable the dynamic fee acceptance from block height 10 onwards:

    "height": 10,
    "fees": {
      "dynamic": true

    The example below will disable dynamic fee processing from block 20 onwards:

    "height": 20,
    "fees":{
      "dynamic": false

    All fees will be calculated according to static fees defined in network.json.

    If you change it don’t forget to restart your Core process to load updated settings.

    This covers basic usage and testing of dynamic fees. See you in #devnet channel on Slack!

    Remember we are also running GitHub bounty program for all pull requests that get merged :  https://blog.ark.io/ark-github-development-bounty-113806ae9ffe


  • ARK Core E2E Testing Automation

    The new Ark V2 Core is much more sophisticated software than our soon to be deprecated Node core. As such, when we designed the system, one of the most important priorities was having great test coverage. With that in mind, we went a step further.

    ARK E2E or ARK End-To-End testing is a custom developed framework by our dev team which enables the writing and running of end-to-end tests in a more automated mode.

    ARK E2E GitHub repository: https://github.com/ArkEcosyste...

    ARK core is already well-covered by unit tests, but with blockchain protocols, this is simply not enough when you want to make sure that it will behave correctly in “real life” environments. Nodes going up, syncing with the network, sometimes getting connection issues, or being shut down - these are the kinds of things that can happen and should be properly handled by the network and thus thoroughly tested. After all, it’s why we do manual testing on DevNet and internal TestNet.

    Automated testing helps to identify issues before they hit DevNet and give the ability to quickly pinpoint where things went wrong, like introducing new code and seeing how it will behave when introduced outside of local testing. All of this is good development practice, but automating some of these “real life” scenarios can only help us improve the quality of our product.

    That’s why we are bringing automation to these situations — this is called “end-to-end”. Its main feature is to generate and launch a fully functional custom network on your machine, with a configurable number of forging nodes.

    On top of this custom network is the testing framework. It allows you to look into the blockchain events in real time and execute actions, like creating transactions and broadcasting it to the network. These end-to-end tests are configured on our continuous integration tool to be run every night. It will pull up the develop branch with the latest commits, run the network from it (current default configuration is 5 nodes) and execute the actions/tests. Going forward, this framework will automate testing scenarios like double spending, double forging, spamming, and other situations.

    What we used to test manually will now be tested every night so we will be able to react quickly when something is wrong and we will progressively add more and more end-to-end tests over time.

    This will not replace manual testing, but it is a new tool in our arsenal that will further improve the quality and resilience of our blockchain core.

    If you want to learn more about ARK E2E back-mechanics you can read “ARK E2E Technical Details”.



Log in to reply
 

Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.