xendoo

The artificial intelligence of the chatbots is revolutionizing the customer experience. They can provide useful information to customers when they need it. Hence, a number of companies that use AI Chatbots have grown exponentially. It provides them with proactive assistance to their customers. Many brands have supercharged their customer service experience with chatbots. It has grown and improved to capitalize on various social networks and messaging platforms. As per the stats, nearly 80% of businesses will have their own Chatbot by 2020 end. It has surpassed usage from 30,000 in 2016 to approx. 100,000 nowadays. Hence, chatbots can now be considered as the new-gen tech. Facebook’s Messenger In this blog, we will look at the various AI Chatbot Platforms that would surely boost up your business revenue. Hiring developers from top chatbot development companies can also benefit you in the long run. Check out the list below: 1) Chatfuel It creates smart and intelligent AI chatbots and allows you to automatically provide answers to frequently asked questions from your customers or prospects, such as in Facebook Messenger. You can even transfer the conversation to a human agent in case your bot cannot answer the question properly. This automation ensures that you never miss a chat from your customers and can continue to provide the assistance they need. Related Blog: How Blockchain & AI Integration is Changing Business Landscape? 2) Meya.AI It has a code editor, live debugger and a visualizer. With the help of Meya, companies can take for their customer service. It helps companies create bots that help their customers in messaging and customer support applications. You can build, train and host your robots in Meya. And you can also easily scale your bots. Meya easily integrates with third-party applications, which increases its ease of use. advantage of AI 3) Imperson This platform develops business AI chatbots that support video, text, audio, AR and VR in the main messaging platforms. Their conversation robots provide authentic and engaging chat experiences for clients. The conversation browser uses the memory of relationships, the attempts of NLP users and the context of a deep dialogue to direct the conversations. And the moderator of artificial intelligence helps to reach the objectives of the clients. Imperson provides an end-to-end bot solution by hosting and deploying your bot and providing information in real time to improve its performance. 4) Flow XO Without having to learn any code, it allows you creating smart chatbots. With its simple drag-and-drop editor, you can create logical workflows and then connect your AI chatbot to the platform you choose. FlowXO integrates with a large number of third-party applications. You can create bots that integrate with services like Salesforce, Google Sheets, Twitter and more. Its hosting and administration features make it one of the best AI chatbot platforms. Read More: Chatbots can make technology more accessible 5) Xenioo Best Part: Free registration Without any line coding, you can build amazing chatbots using this easy-to-use platform. It allows you to instantly build and launch intelligent chat chats for your website or any social networking platforms. You can use it for multiple channels, including Slack, Amazon, Facebook, WhatsApp, Telegram, and many more. In addition, these AI chatbots are able to understand and respond to complex and multilingual expressions with the help of the NLP engine integrated into the platform. It even has a training module that allows you to train chat chats by creating intentions and expressions. Read Blog: Top Chatbot Development Companies For SME's and Startups 6) Botsify It helps you create smart AI chatbots for your website or slack without having to spend your time and efforts on coding. Botsify offers multiple add-ons to help you integrate it with your Shopify store, RSS feed, Google Sheets, or Google search. It has an easy-to-use drag-and-drop UI and is powered by artificial intelligence and machine learning. This allows machine learning developers to seamlessly transfer the conversation from a bot to a human agent in situations where the bot is not properly equipped to assist the client. Theplatform also presents conversation forms through which you can collectinformation about your potential customers through chatbot conversations. 7) MobileMonkey You can use it to manage a series of lead generation activities, such as chat streams, drip campaigns, and list creation. It also allows you to automate customer service by providing answers to frequently asked questions and reduces waiting time. You can even cancel your AI chatbot and jump into the conversation at any time, without problems. It helps you build chatbots which can take your Facebook Messenger marketing to the next level. 8) Aivo It is one of the best AI chatbot platforms as it enhances customer support experience and helps organizations respond in real time through text or voice. It can help you increase conversions and optimize your resources. Aivo’s AgentBot can be easily integrated with third-party platforms such as Zapier, Live, Zendesk, Salesforce and many others. It adapts to the rules of a channel and responds automatically to provide its customers with a personalized experience. 9) Pandorabots Pandorabots provides solutions for the complete development of turnkey chatbot. This platform is one of the oldest and largest AI chatbot hosting services in the world. It allows bidirectional communication to scale. You can create and implement chatbots on your website, mobile applications and popular messaging platforms such as Line, KiK, Twitter, Telegram, and Slack. Pandorabots implements and supports AIML open standards. 10) ManyChat For marketing, sales and support systems, it helps you easily create Facebook Messenger chatbots. Its visual creator of drag-and-drop bots helps you set up a Facebook Messenger bot in no time. It helps you transmit your messages effectively. You can also automate your Messenger marketing and send messages based on delays or certain user actions. It also provides you with a set of tools to help you increase your Messenger audience. 11) Boost.ai It can help companies to build conversational chatbots. This can help you provide faster support to your customers and automatically reduce your waiting time by providing answers to frequently asked questions. It has an easy-to-use API along with a conversation flow editor that helps you easily train your AI chatbot without requiring any technical knowledge. Boost has been successfully tapped by leading companies in domains viz. human resources, telecommunications, banking, insurance, and even in the public sector. Hence, it is one of the best AI chatbot creation platforms. Final Note: So far we have seen some major AI chatbot platforms that let to enhance their customer experience. You can even broadcast your special offers and other messages easily using these chatbots. Ultimately, these will help you provide efficient and quick customer support. companies build smart and intelligent chatbots However, we have listed our best AI chatbot platforms for the businesses in 2019–20. : I work at , a company that creates Chatbot Solutions Disclosure Value Coders

Eleven Trending AI Chatbot Platforms

The privacy coin project Horizen team once claimed: "If Satoshi Nakamoto wants to design a sidechain for Bitcoin, then he should design something analogous to Zendoo." Zendoo here is the sidechain protocol designed by the Horizen team. Let's study the Zendoo protocol white paper today. The Zendoo white paper was jointly written by the Horizen team and the IOHK team. The protocol supports a sidechain of any type, including the sidechain of the UTXO model, the sidechain of smart contracts, and even an ordinary centralized application. It is understandable that the Zendoo protocol only supports cross-chain funds because Horizen is a UTXO-model private currency public chain that does not support smart contracts, hence the cross-chain agreement is only cross-chain funds. Zendoo utilizes zero-knowledge proofs to support a decentralized approach to achieve cross-chain purposes. The Cross-Chain Mode There are four cross-chain modes in total: Let's further study: FT (Forward Transfer) FT operates on the main blockchain: it transfers the assets on the main blockchain to the sidechains. The protocol is also quite simple: the main blockchain treats FT as a special transaction, destroying coins on the main blockchain and providing metadata concerning the payment on the sidechains. The side chain needs to monitor the main blockchain in real-time. If the latest block of the main chain does not contain FT transactions, the side chain will only use the hash of the block in the main blockchain as a reference and add it to the side chain; if the latest block of the main blockchain contains FT transactions, the entire block header, all FT transactions, and the Merkle path of all FT transactions will be introduced into the side chain as a reference. In this way, anyone on the side chain is able to verify whether the transaction is legal instead of going to the main blockchain for query verification. BT（Backward Transfer） BT operates on the side chain and transfers the assets on the side chain to the main blockchain. As mentioned before, IOHK is also one of the authors of the Zendoo white paper, so we can see the resemblance of the Ouroboros protocol in the design of BT. Like the Ouroboros protocol, the protocol design of BT also involves the concepts of epoch and slot, as shown in the figure above. A withdrawal epoch is composed of lens and slots, and the len has different parameters for different side chains. If a withdrawal certificate is not submitted to the main chain within this period of time, the side chain will be considered as ceased (for instance, a withdrawal certificate in epoch is not submitted to the main blockchain in the first len blocks in epoch +1), and subsequent withdrawal certificates will not be accepted by the main blockchain, but the funds of the side chain can still be withdrawn. The B in the above figure is a slot. The side chain forger (block producer) will package the slot with BT signature and submit the withdrawal application certificate to the main blockchain within the specified epoch time. Regarding the withdrawal certificate, we will talk about it later. i i The main blockchain does not care about the role of submitting the withdrawal certificate, and the way the withdrawal certificate should be packaged is a consideration for the side chain but not for the main blockchain. BT = (receiverAddr, amount) Among them： receiverAddr-the address of the recipient on the main blockchain amount - transfer amount A Withdrawal Certificate (WCert, Withdrawal Certificate) is a standardized posting that allows the side chain to communicate with the main blockchain. This requires at least 51% of the block producer signatures to prevent fraud, and then send it to the main blockchain. The main functions are: Send BT to the main blockchain As a heartbeat message, the main blockchain can identify the state of the side chain It is defined as below: WCert = (ledgerId, epochId, quality, BTList, proofdata, proof) Among them: ledgerId-sidechain id to create WCert epochld-the id of a withdrawal epoch, generally increasing in order quality-indicates the quality of this withdrawal certificate (actually, it is the block height of the last status update) BTList-an array of multiple withdrawal transactions within a withdrawal period Proofdata-public input parameters used by SNARK verifiers Proof-the proof used by the SNARK verifier The main blockchain contains vk (written when the sidechain is registered), and the certificate generator of the sidechain (can be anyone) contains pk. true/false <- verify (vk, public_input, proof) public_input = (wcert_sysdata, MH (proofdata)) wcert_sysdata = (quality, MH(BTList), H(Bi-1), H(Bi)) proofdata = (H(SB_last), H(state_SB_last [MST]), mst_delta) Among them: Bi-1-the last block hash of i-1 withdrawal epoch in the main blockchain Bi-the last block hash of i withdrawal epoch in the main blockchain H(SB_last)-the last block hash of the i withdrawal epoch sidechain H(state_SB_last[MST])-the Merkle hash after updating the state SB_last mst_delta - bit vector modified by MST. Since MST is a fixed-size tree, mst_delta is also a fixed-size bit vector, and each bit represents a leaf of the tree. This is applied for data visibility. In the UTXO model, withdrawal data can be restored on the main blockchain without the need for sidechain data. Bit vector algorithm As demonstrated in the above figure, an MST is in a depth of 3 leaves and with a node of 2³. The grey leaf node indicates that there is an update, and the white leaf node indicates that there is no update. The bit vector algorithm is used to represent the change of MST, which is: mst_delta = (10111001)` The algorithm can effectively in the Data Availability characteristic expansion scheme, that is, , and the root hash after the MST change can verify the legality of the data. For L1 verifiers, it is not necessary to verify all the data but just the changed state. save the data on the chain every time only the transmission of the changed delta value, the root hash before the MST change Surely, if there are large volumes of data and the MST has a lot of leaves, then the bit vector will also be large and will consume a lot of gas. This is the direction that needs to be optimized in the future. 2. BTR（Backward Transfer Request） It is possible that users cannot perform BT operations on the sidechain. For example, the RPC address on the sidechain refuses to access. At this time, if one wants to retrieve the funds on the sidechain to the main blockchain, one can only initiate a BTR operation on the main blockchain. BTR will not directly transfer funds on the main chain, but synchronize this BTR to the sidechain, and go through the process analogous to BT (excluding the user's active part) on the sidechain. BTR = (ledgerId, receiver, amount, nullifier, proofdata, proof) Among them: ledgerId -sidechain id receiver -the recipient on the main blockchain amount - transfer amount nullifier -the unique identifier of this claimed coin (similar to the nonce in Ethereum, anti-double spending) proofdata - publicly entered parameters, which will be discussed in detail later proof -proof of zero-knowledge proof The vk and pk in a ZKSnark protocol are public, so anyone can employ vk to verify the correctness of the proof. true/false <- verify(vk, public_input, proof) public_input = (btr_sysdata, MH(proofdata)) btr_sysdata = (H(Bw), nullifier, receiver, amount) Among them: Others are the same as the above-mentioned WCert, H(Bw) is the block hash of the main blockchain when this sidechain submits the last withdrawal certificate. 3. CSW（Cessed Sidechain Withdrawal） When the sidechain does not respond, for example, the sidechain is attacked or the heartbeat message is not sent to the main blockchain within the specified time. At this time, the funds on the sidechain need to be withdrawn from the main blockchain. It is defined as follows: CSW = (ledgerId, receiver, amount, nullifier, proofdata, proof) The meaning of the parameters is the same as that of BTR. Unlike BTR, CSW will not go to the sidechain to follow the BT process (because the sidechain has no response at the time), but directly complete the transfer on the main blockchain. Detailed Design Withdrawal Safeguard Set a global variable on the main blockchain, increase the corresponding transfer amount when performing FT, decrease the corresponding amount when performing BT, and when withdrawing, the amount cannot be greater than this amount. (This function is easier to implement in smart contracts.) Main Blockchain Refers to Sidechain In order to synchronize the main blockchain and the sidechain, an extra field is included in the block header of the main blockchain to commit all operations related to the sidechain in the main chain block (except CSW, used when the sidechain is ceased). Introducing is to include the root hash of the Merkle tree that is related to all transactions or output concerning the sidechain. scTxsCommitment (Sidechain Transactions Commitment) For example: type MCBlockHeader { prevBlock: BlockId, height: int, … scTxsCommitment: Hash, } Sidechain Refers to Main Blockchain The sidechain (SC) block contains the high reference (or hash) of the main chain (MC), which has two advantages: The sidechain can be synchronized quickly The main chain is forked, and the sidechain can be referenced as a rollback point based on the final height of the main chain As can be seen from the above figure, the main chain block may contain sidechain-related transactions, and the transactions will also be included in the sidechain block, which will also reference the main chain block. Among them, the sidechain contains a reference to the main chain: type MCBlockRefrence { header: MCBlockHeader, mproof: Option [MerkleProof], proofOfNoData: Option [MerkleProof], forwardTransfers: Option [FTTx], btRequests: Option [BTRTx], wcert: Option [WCert], } header- the header that refers to a certain MC block mproof-optional, if the MC block contains at least one transaction related to this SC, this field is used for the Merkle root of the SC, otherwise, it is empty. proofOFNoData-optional forwardTransfers-MC cross-chain to SC btRequests -Request to redeem funds from SC to MC WCert-withdrawal certificate Proof Combination Composing SNARKs recursively can transfer multiple states and finally generate a proof. The transfer (BT/BTR) form of a single token is fixed, so the basic circuit is universal. For example,  ERC20 is implemented in the form of "transfer". Then, base_proof can be aggregated to finally generate a proof. This form of aggregation is actually MMR (Merkle Mountain Range). Then the MMR will be discussed in detail as below. Merkle Mountain Range (MMR) For the aggregation proof of the ordinary Merkle Tree structure, if one wants to aggregate the proofs of 10 transactions into one proof, one needs to aggregate the leaf nodes in pairs. If the proofs of some of the leaf nodes are not yet ready (for example, we set that 10 transactions can generate a base_proof in the ZK Rollup. At this time, 8 transactions may be ready, but the remaining two have not yet occurred), the entire prove process will wait until the leaf node's proof is ready, and then make the aggregation in pairs, and finally aggregate sequentially to generate a merge_proof. MMR has improved the Merkle tree structure. It can first aggregate the generated base_proofs in pairs to generate merge_proof, and then aggregate merge_proofs in pairs to generate merge_proof. As shown in the figure above, when the transactions Tx9 and Tx10 are not yet ready, the base_proofs of the previous 8 transactions can be aggregated to generate the merge_proof (1->8), and after Tx9 and Tx10 are completed, combine this two base_proof to generate a merge_proof (9->10), and then aggregates the proof with the ready merge_proof (1->8) to generate the final merge_proof (1->10). Compared with the aggregation proof of the Merkle tree, MMR has the following characteristics: The efficiency of generating aggregated proofs is high, and the proof time is greatly reduced The structure is more flexible, and base_proof and merge_proof can be aggregated Certificate Submission When submitting, only the node maintainer (Forger/Slot leader) is eligible to be rewarded after submission, and within a specific submission period. If the submission fails or is not submitted within the time limit, it will be postponed to the next competitor. (Slot leader election uses the smallest block hash of an epoch on the main chain to generate random numbers.) In Latus, both the block producer and the prover are rewarded, and the block producer packs, while the prover generates a certificate. For basic state transitions, prove and verify are: proof^{Base}{a} = Prove(pk^{Base}{a}, (s_i, s_{i+1}), (tx_a)) true/false = Verify(vk^{Base}{a}, (s_i, s{i+1}), proof^{Base}{a}) Among them: a ∈ {pay, FT, BT, BTR} {i+1} are public inputs, si= Hash(State_i), that is, public input is the hash before and after the state transition, for Latus, it is the merkle tree root hash s_i，s For the merged SNARK, prove and verify are: proof^{Merge} = Prove(pk^{Merge}, (s_i, s_{i+k}), (s_{i+j}, proof^b_1, proof^c_2)) true/false = Verify(vk^{Merge}, (s_i, s_{i+k}), proof^{Merge}) Among them: b,c ∈ {Base, Merge} proof^b_1 proves that there is such a transaction, tx_1, …, tx_j, enables State_{i+j} = update ([tx_i, …, tx_j], State_i) proof^c_2 proves that there is such a transaction, tx_{j+1}, …, tx_k, enables State_{i+k} = update([tx_{j+1}, …, tx_k], State_{i+j}) Summary Judging from the white paper, Zendoo and ZK Rollup are quite similar. For Data Availability, the former involves the cross-chain generation of proofs, and sidechain transfers cannot generate. The latter will generate proofs for all L2 transactions and submit them to L1 verification. For withdrawal, Zendoo has BT/BTR/CSW, and ZK Rollup has similar operations such as Withdraw/Exit/Force_exit. For MST data maintenance, the existing ZK Rollup implementation basically applies a single node or a centralized node, while the Zendoo node is decentralized storage. Compared with the current popular Polygon, Zendoo is decentralized in the cross-chain form, and anyone can submit a ZK proof, while Polygon applies authorized multi-signature bridges to control the billing on both sides of the contract to achieve cross-chain. As for the withdrawal time, Zendoo needs to generate a proof and submit it to the chain, the process which is more time-consuming, while Polygon is more centralized and time-controllable. Regarding the difficulty of implementation, Zendoo also needs a prover for generating proof in addition to the node. This requires the realization of a zero-knowledge proof circuit, which is more difficult to develop, while Polygon only needs to implement multi-signature contract control. Reference https://heap.horizen.io/ https://www.horizen.io/assets/files/Horizen-Sidechain-Zendoo-A_zk-SNARK-Verifiable-Cross-Chain-Transfer-Protocol.pdf https://www.horizen.io/assets/files/whitepaper-snarks.pdf https://academy.horizen.io/horizen/expert/sidechains/

Zendoo Protocol: A Deep Dive

Welcome to another insightful edition of the "Behind the Startup" series, where we dive into the journeys of groundbreaking startups within the blockchain sphere. Today, we are joined by Rob Viglione, co-founder of Horizen Labs, who will share the comprehensive saga of Horizen's evolution since its inception in 2017. Join us as Rob recounts the milestones, technological pivots, and strategic decisions that have shaped Horizen's path towards becoming a hub for zero-knowledge projects. Ishan Pandey: Hello Rob, It's a pleasure to welcome you to our 'Behind the Startup' series. Could you share the full story of Horizen Labs with us? We'd love to hear it, especially the challenges and victories you faced along the way. Feel free to share it all! Rob Viglione: Horizen Labs started in 2019 as a protocol developer for Horizen, an open-source blockchain project launched in 2017. We’ve established a niche for ourselves as web3 experts through our work on a number of high-profile industry projects, including in the Ape ecosystem (ApeCoin, ApeChain, Otherdeeds); the Bitcoin ecosystem (Opal); and last but not least, the Horizen ecosystem. We’re now laser-focused on developing a modular blockchain solution within Horizen optimized for proof verification as the first step on a broader mission to turbocharge Horizen as a hub for zero-knowledge projects. Ishan Pandey: Can you explain the shift towards making Horizen a hub for ZK technologies in Web3 and how it aligns with the platform's evolution since 2017? Rob Viglione: For us, it’s less a shift than the next stage of a natural progression. Zero-knowledge cryptography has always been at the heart of Horizen. Initially, that expertise was applied towards ensuring privacy on-chain; then, to permissionless scalability with our interoperability protocol, Zendoo; and now to modular proof verification. The through-line has always been using zk-cryptography to solve the industry’s biggest challenges. As I just alluded to, we’re now building a modular blockchain optimized for verifying zero-knowledge proofs. However, that’s just the first step in a much bigger mission to enable new types of cryptography to be used in Web3 that's not possible today with the verification constraints on Ethereum. Ishan Pandeey: How does Horizen plan to leverage its position as a pioneer in ZK technology to differentiate itself in the market and attract ZK projects to its ecosystem? Rob Viglione: The first is through our pure technological advantage. Because we have so much experience in zk cryptography, including a world-class team of cryptographers and cryptographic engineers, we have a true competitive edge. Our team has even invented a couple of highly efficient hash functions that’ll play a role in our technology, including Poseidon2 and Monolith. Our proof verification layer, currently on testnet, collapses verification costs by 90% to as much as 99% versus verifying on Ethereum. That performance speaks for itself and makes our go-to-market easy. Beyond that, though, is our reputation and support throughout the industry. Because of the Horizen heritage and brand, we are able to attract the best builders, innovators, and talent in the ZK space. Horizen has demonstrated its commitment to the ZK industry for almost seven years now, and we’ve seen the fruits of that commitment as we’ve had many projects and partners sign on to become part of what we’re building. That will only intensify in the coming weeks and months, and we’re so excited for what’s coming. Ishan Pandey: Considering the competitive environment and the emergence of new projects offering proof verification solutions, how does Horizen intend to maintain relevance and compete effectively with its existing tokenomics? Rob Viglione: It’s true that we’re not the only ones operating in this market segment. But we are the only ones with seven years (or anything close to it) of experience, connections, and support in the ZK space. In my blog post, I’ve laid out my vision for Horizen and $ZEN, and explained why I thought that a new token dedicated to the proof verification layer would be beneficial. Given that Horizen began as a fork of Zcash–which was itself a fork of bitcoin–it inherited its tokenomics from bitcoin. The fixed supply cap of 21 million tokens is a significant component of $ZEN’s identity and appeal, and I feel strongly that this cap should be preserved. With all of this as a backdrop, I proposed in my blog post that a new token be adopted for the  upcoming proof verification chain. This way, $ZEN’s core tokenomics are unchanged, and the proof verification layer benefits from a cryptocurrency optimized for it specifically. Ishan Pandey: What are the potential benefits of adopting a new token for the proof verification layer, and how does this align with Horizen's mission and vision? Rob Viglione: I’ll preface this by saying that any potential token for the proof verification would need to be adopted by the community, and that I’m speaking as a community member and co-founder of Horizen. But the main benefit of a cryptocurrency dedicated to the proof verification layer would be to incentivize the desired on-chain activity–in this case, proof verification. How this would work in practice could play out in any number of ways, but the main point is to facilitate the activity for which the blockchain was purpose-built. Ishan Pandey: As blockchain technology and cryptocurrency adoption continue to grow, regulatory scrutiny intensifies. What are your views on regulatory challenges in the Web3 ecosystem? Rob Viglione: I’ve long said that regulation would benefit the web3 industry, provided that it’s done in a thoughtful and constructive way. Clear rules that establish guidelines for participants in the ecosystem would foster the certainty and confidence needed for the industry to grow much more from here. I’m doing my part by assisting efforts by industry trade associations to work with policymakers and help shape constructive regulations. Don’t forget to like and share the story! Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program. HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR. Welcome to another insightful edition of the "Behind the Startup" series, where we dive into the journeys of groundbreaking startups within the blockchain sphere. Today, we are joined by Rob Viglione, co-founder of Horizen Labs, who will share the comprehensive saga of Horizen's evolution since its inception in 2017. Join us as Rob recounts the milestones, technological pivots, and strategic decisions that have shaped Horizen's path towards becoming a hub for zero-knowledge projects. Ishan Pandey: Hello Rob, It's a pleasure to welcome you to our 'Behind the Startup' series. Could you share the full story of Horizen Labs with us? We'd love to hear it, especially the challenges and victories you faced along the way. Feel free to share it all! Ishan Pandey: Ishan Pandey: Hello Rob, It's a pleasure to welcome you to our 'Behind the Startup' series. Could you share the full story of Horizen Labs with us? We'd love to hear it, especially the challenges and victories you faced along the way. Feel free to share it all! Rob Viglione: Horizen Labs started in 2019 as a protocol developer for Horizen, an open-source blockchain project launched in 2017. We’ve established a niche for ourselves as web3 experts through our work on a number of high-profile industry projects, including in the Ape ecosystem (ApeCoin, ApeChain, Otherdeeds); the Bitcoin ecosystem (Opal); and last but not least, the Horizen ecosystem. We’re now laser-focused on developing a modular blockchain solution within Horizen optimized for proof verification as the first step on a broader mission to turbocharge Horizen as a hub for zero-knowledge projects. Rob Viglione: Ishan Pandey: Can you explain the shift towards making Horizen a hub for ZK technologies in Web3 and how it aligns with the platform's evolution since 2017? Ishan Pandey: Ishan Pandey: Can you explain the shift towards making Horizen a hub for ZK technologies in Web3 and how it aligns with the platform's evolution since 2017? Rob Viglione: For us, it’s less a shift than the next stage of a natural progression. Zero-knowledge cryptography has always been at the heart of Horizen. Initially, that expertise was applied towards ensuring privacy on-chain; then, to permissionless scalability with our interoperability protocol, Zendoo; and now to modular proof verification. The through-line has always been using zk-cryptography to solve the industry’s biggest challenges. Rob Viglione: As I just alluded to, we’re now building a modular blockchain optimized for verifying zero-knowledge proofs. However, that’s just the first step in a much bigger mission to enable new types of cryptography to be used in Web3 that's not possible today with the verification constraints on Ethereum. Ishan Pandeey: How does Horizen plan to leverage its position as a pioneer in ZK technology to differentiate itself in the market and attract ZK projects to its ecosystem? Ishan Pandeey: How does Horizen plan to leverage its position as a pioneer in ZK technology to differentiate itself in the market and attract ZK projects to its ecosystem? Ishan Pandeey: How does Horizen plan to leverage its position as a pioneer in ZK technology to differentiate itself in the market and attract ZK projects to its ecosystem? Rob Viglione: The first is through our pure technological advantage. Because we have so much experience in zk cryptography, including a world-class team of cryptographers and cryptographic engineers, we have a true competitive edge. Our team has even invented a couple of highly efficient hash functions that’ll play a role in our technology, including Poseidon2 and Monolith. Our proof verification layer, currently on testnet, collapses verification costs by 90% to as much as 99% versus verifying on Ethereum. That performance speaks for itself and makes our go-to-market easy. Rob Viglione: Beyond that, though, is our reputation and support throughout the industry. Because of the Horizen heritage and brand, we are able to attract the best builders, innovators, and talent in the ZK space. Horizen has demonstrated its commitment to the ZK industry for almost seven years now, and we’ve seen the fruits of that commitment as we’ve had many projects and partners sign on to become part of what we’re building. That will only intensify in the coming weeks and months, and we’re so excited for what’s coming. Ishan Pandey: Considering the competitive environment and the emergence of new projects offering proof verification solutions, how does Horizen intend to maintain relevance and compete effectively with its existing tokenomics? Ishan Pandey: Ishan Pandey: Considering the competitive environment and the emergence of new projects offering proof verification solutions, how does Horizen intend to maintain relevance and compete effectively with its existing tokenomics? Rob Viglione: It’s true that we’re not the only ones operating in this market segment. But we are the only ones with seven years (or anything close to it) of experience, connections, and support in the ZK space. In my blog post, I’ve laid out my vision for Horizen and $ZEN, and explained why I thought that a new token dedicated to the proof verification layer would be beneficial. Given that Horizen began as a fork of Zcash–which was itself a fork of bitcoin–it inherited its tokenomics from bitcoin. The fixed supply cap of 21 million tokens is a significant component of $ZEN’s identity and appeal, and I feel strongly that this cap should be preserved. With all of this as a backdrop, I proposed in my blog post that a new token be adopted for the  upcoming proof verification chain. This way, $ZEN’s core tokenomics are unchanged, and the proof verification layer benefits from a cryptocurrency optimized for it specifically. Rob Viglione: Ishan Pandey: What are the potential benefits of adopting a new token for the proof verification layer, and how does this align with Horizen's mission and vision? Ishan Pandey: Ishan Pandey: What are the potential benefits of adopting a new token for the proof verification layer, and how does this align with Horizen's mission and vision? Rob Viglione: I’ll preface this by saying that any potential token for the proof verification would need to be adopted by the community, and that I’m speaking as a community member and co-founder of Horizen. But the main benefit of a cryptocurrency dedicated to the proof verification layer would be to incentivize the desired on-chain activity–in this case, proof verification. How this would work in practice could play out in any number of ways, but the main point is to facilitate the activity for which the blockchain was purpose-built. Rob Viglione: Ishan Pandey: As blockchain technology and cryptocurrency adoption continue to grow, regulatory scrutiny intensifies. What are your views on regulatory challenges in the Web3 ecosystem? Ishan Pandey: Ishan Pandey: As blockchain technology and cryptocurrency adoption continue to grow, regulatory scrutiny intensifies. What are your views on regulatory challenges in the Web3 ecosystem? Rob Viglione: I’ve long said that regulation would benefit the web3 industry, provided that it’s done in a thoughtful and constructive way. Clear rules that establish guidelines for participants in the ecosystem would foster the certainty and confidence needed for the industry to grow much more from here. I’m doing my part by assisting efforts by industry trade associations to work with policymakers and help shape constructive regulations. Rob Viglione: Don’t forget to like and share the story! Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program. HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR. Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program . HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR. Vested Interest Disclosure: business blogging program business blogging program

How Horizen is Redefining Blockchain with Zero-Knowledge Proofs

হরিজেন কীভাবে শূন্য-জ্ঞান প্রমাণ সহ ব্লকচেইনকে পুনরায় সংজ্ঞায়িত করছে

Wie Horizen Blockchain mit Zero-Knowledge-Beweisen neu definiert

Cómo Horizen está redefiniendo Blockchain con pruebas de conocimiento cero

Comment Horizen redéfinit la blockchain avec des preuves sans connaissance

होराइजन कैसे शून्य-ज्ञान प्रमाणों के साथ ब्लॉकचेन को पुनर्परिभाषित कर रहा है

Horizen がゼロ知識証明でブロックチェーンを再定義する方法

Horizen이 영지식 증명으로 블록체인을 재정의하는 방법

Como a Horizen está redefinindo o Blockchain com provas de conhecimento zero

Как Horizen переосмысливает блокчейн с помощью доказательств с нулевым разглашением

Horizen Sıfır Bilgi Kanıtlarıyla Blockchain'i Nasıl Yeniden Tanımlıyor?

Horizen đang định nghĩa lại Blockchain bằng Bằng chứng không có kiến thức như thế nào

Horizen 如何利用零知识证明重新定义区块链

Navigating Privacy Tokens: Horizen's Proactive Compliance Measures with ZenIP 42207

Stories, News & Mentions about XENDOO

Xendoo’s Stories on HackerNoon